update #19
update #19
Conversation
|
Important Review skippedToo many files! 39 files out of 189 files are above the max files limit of 150. You can disable this status message by setting the WalkthroughThis pull request updates CyberPot to version 24.04.1, adds build infrastructure (Makefile and docker-build.sh), introduces automated ISO generation scripts, expands Ansible support for RedHat distributions, and adjusts image registries and paths across numerous Docker services. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~65 minutes Poem
🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 16
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (4)
docker/elk/kibana/Dockerfile (1)
39-39: Remove the--optimizeflag—it was removed in Kibana 8.0 and does not exist in Kibana 9.2.3.The Dockerfile specifies
KB_VER=9.2.3, but line 39 attempts to runkibana --optimize, which is incompatible. The--optimizeflag (and legacyoptimize.*settings) have been removed entirely. Either remove the flag or update the build process to use Kibana's modern optimizer (@kbn/optimizer).installer/install/cyberpot.yml (1)
59-65: Bug: Wrongwhencondition for openSUSE Tumbleweed python installation.The condition checks for
["AlmaLinux", "Fedora", "Rocky"]but this task is tagged for openSUSE Tumbleweed. The python package will never be installed on openSUSE systems.Suggested fix
- name: Add python package (openSUSE Tumbleweed) raw: | zypper refresh zypper -y install python3 - when: my_distribution.stdout | trim in ["AlmaLinux", "Fedora", "Rocky"] and my_python3.stdout | trim == "" + when: my_distribution.stdout | trim in ["openSUSE Tumbleweed"] and my_python3.stdout | trim == "" tags: - "openSUSE Tumbleweed".env (2)
112-114: Invalid .env syntax: colons instead of equals signs.These lines use YAML-style colon syntax (
:) instead of the standard.envequals sign syntax (=). Docker Compose.envfiles requireKEY=valueformat. This will cause the variables to be incorrectly parsed.Proposed fix
-BEELZEBUB_LLM_MODEL: "ollama" -BEELZEBUB_LLM_HOST: "http://ollama.local:11434/api/chat" -BEELZEBUB_OLLAMA_MODEL: "openchat" +BEELZEBUB_LLM_MODEL="ollama" +BEELZEBUB_LLM_HOST="http://ollama.local:11434/api/chat" +BEELZEBUB_OLLAMA_MODEL="openchat"
127-129: Same syntax issue: colons instead of equals signs.Apply the same fix as above for the GALAH configuration variables.
Proposed fix
-GALAH_LLM_PROVIDER: "ollama" -GALAH_LLM_SERVER_URL: "http://ollama.local:11434" -GALAH_LLM_MODEL: "llama3.1" +GALAH_LLM_PROVIDER="ollama" +GALAH_LLM_SERVER_URL="http://ollama.local:11434" +GALAH_LLM_MODEL="llama3.1"
🤖 Fix all issues with AI agents
In @.env:
- Line 15: The WEB_USER environment variable contains hardcoded credentials;
remove the encoded value for WEB_USER and replace it with an empty value or a
non-secret placeholder, move the actual credential into a local-only env file
(e.g., use a separate env file that is not committed) and ensure that local
secret env files are ignored by adding them to .gitignore; also rotate the
exposed credential. Reference: update the WEB_USER entry to avoid committing
secrets.
- Line 152: The CYBERPOT_VERSION value in .env is inconsistent with update.sh's
myMASTERVERSION and env.example; change the CYBERPOT_VERSION variable in the
.env file from "24.04" to "24.04.1" so it matches myMASTERVERSION="24.04.1" in
update.sh and the version in env.example to ensure docker-compose pulls the
correct image tag.
In `@CHANGELOG.md`:
- Line 32: The deprecation line in CHANGELOG.md incorrectly names the new
release (24.04.1) as being removed; update the notice to reference the
superseded old version (e.g., change "24.04.1" to "24.04") so it reads that the
old 24.04 images will be removed by 2025-01-31, and double-check the surrounding
changelog entries mention 24.04.1 as the new release for consistency.
In `@compose/standard.yml`:
- Around line 710-711: Kibana's image is hardcoded as
"khulnasoft/kibana:24.04.1" which breaks consistency; change the image value for
the Kibana service to use the existing repo/version variables (e.g., replace the
hardcoded string with "${CYBERPOT_REPO}/kibana:${CYBERPOT_VERSION}") so it
follows the same pattern as other services and continues to use the
CYBERPOT_PULL_POLICY for pulls.
In `@docker-build.sh`:
- Around line 74-90: The find | while read loop runs in a subshell so failures
in the docker build inside that loop won't trigger script exit; replace the
pipeline with process substitution (use while read -r dockerfile; do ... done <
<(find docker -name Dockerfile ...) or use find -print0 with while IFS= read -r
-d '' dockerfile; do ... done < <(find ... -print0) to run the loop in the main
shell, and after the (cd "$dir" && docker build -t "$tag" .) check the build
exit status (or simply let set -e handle it in the main shell) and exit non-zero
on failure so the final echo "All Docker images built successfully." only runs
when all builds succeed; keep references to variables image_name, tag,
relative_path and the docker build invocation so you update the correct loop.
In `@docker/elk/kibana/Dockerfile`:
- Around line 1-2: In the Dockerfile remove the deprecated --optimize flag from
the Kibana startup command: locate the invocation of
/usr/share/kibana/bin/kibana (the CMD/ENTRYPOINT that currently includes
"--optimize --allow-root") and delete the "--optimize" token so the container
starts with "/usr/share/kibana/bin/kibana --allow-root" (or equivalent startup
args for Kibana 9.x); do not add any replaced optimization flag since --optimize
was removed in 9.x.
In `@docker/ewsposter/Dockerfile`:
- Around line 36-37: The Dockerfile currently performs an unpinned git clone
("git clone https://github.com/telekom-security/ewsposter /opt/ewsposter") which
makes builds non-reproducible; replace that unpinned clone with the
version-pinned command (the commented line using "-b V1.30.0") so the repository
is cloned at the V1.30.0 tag/branch (remove or replace the active unpinned "git
clone" and restore the commented "-b V1.30.0" invocation in the Dockerfile).
In `@docker/nginx/builder/esvue/Dockerfile`:
- Around line 1-3: Remove or update the outdated top-line comment in the
Dockerfile that claims Elasticvue build is broken and references issue `#215`;
since the Docker build using the FROM node:22.21.1-alpine and the npm install /
npm run build workflow successfully produces Elasticvue v1.11.1, either delete
the two comment lines or replace them with a short note stating the build is
confirmed working with node:22.21.1-alpine and npm, and include a version/date
if desired to document the current stable state.
In `@install.sh`:
- Line 5: The script currently sets myCYBERPOT_CONF_FILE=".env", which breaks
when install.sh is run from a different CWD; change it to compute the
script/project directory using ${BASH_SOURCE[0]} (e.g. script_dir="$(cd
"$(dirname "${BASH_SOURCE[0]}")" >/dev/null 2>&1 && pwd)") and set
myCYBERPOT_CONF_FILE="$script_dir/.env" (or adjust to the project root if
install.sh lives in a subdir), ensuring any file reads/writes use that absolute
path so the .env is always resolved relative to the repository, not the current
working directory.
In `@installer/install/cyberpot.yml`:
- Around line 506-513: The RHEL Ansible task named "Copy resolv.conf to
/etc/systemd (RHEL)" uses the wrong filename; update the task so both the
copy.src and copy.dest use "resolved.conf" (i.e., change
/usr/lib/systemd/resolv.conf -> /usr/lib/systemd/resolved.conf and
/etc/systemd/resolv.conf -> /etc/systemd/resolved.conf) so it matches the Fedora
task and the standard systemd-resolved naming.
In `@iso-build/build.sh`:
- Around line 86-88: The mounts for /dev, /proc and /sys under CHROOT_DIR are
not protected by a cleanup trap, so if the script exits early the
pseudo-filesystems remain mounted; add a cleanup function (e.g., cleanup_chroot)
that checks for and unmounts "${CHROOT_DIR}/dev", "${CHROOT_DIR}/proc" and
"${CHROOT_DIR}/sys" (use safe unmount checks and fallbacks like umount -l if
necessary), register it with trap 'cleanup_chroot' on EXIT ERR INT TERM, and
call or skip it appropriately before the existing unmount lines to ensure mounts
added by the mount --bind and mount -t proc/sysfs commands are always cleaned
up.
- Line 18: The script creates BUILD_DIR with mktemp -d but then immediately
removes it with rm -rf "${BUILD_DIR}"; fix by ensuring the cleanup targets
previous builds only: either move the rm -rf cleanup block (the rm -rf
"${BUILD_DIR}" call at the block covering lines ~70-72) to run before you create
BUILD_DIR with mktemp -d, or introduce and use a separate variable (e.g.,
PREV_BUILD_DIR or CLEANUP_DIR) for the cleanup logic and ensure the rm only
operates on that variable and never on BUILD_DIR; update the cleanup condition
so it skips when the target equals the freshly created BUILD_DIR and adjust
references in build.sh accordingly.
In `@iso-build/custom-scripts/cyberpot-first-boot.sh`:
- Around line 13-15: Add a cleanup function (e.g., cleanup_tempuser) and install
a trap before creating the temporary account so the user is always removed on
exit/failure: define cleanup_tempuser to check for the existence of user
"tempuser" and delete it with its home (e.g., deluser --remove-home or userdel
-r), set trap 'cleanup_tempuser' EXIT right before the useradd/chpasswd/adduser
lines, and if you need to retain the account on successful completion remove or
clear the trap (trap - EXIT) after the successful path; ensure the cleanup
function is idempotent and safe to call even if the user was never created.
In `@iso-build/preseed.cfg`:
- Around line 21-29: Remove hardcoded plaintext passwords set by d-i
passwd/root-password and d-i passwd/user-password in preseed.cfg; instead either
(A) remove those lines and require interactive password entry or use a hashed
password mechanism, and update documentation to instruct users to change
passwords immediately after install, or (B) keep automated setup but add a
post-install step (via late_command) that forces password reset on first login
(e.g., run chage -d 0 for the 'root' and 'cyberpot' user) and remove/avoid
user-setup/allow-password-weak enabling insecure defaults; ensure the chosen
approach updates the README/installation docs to state the enforced
password-change behavior.
- Line 52: The preseed entry sets grub-installer/bootdev to a hardcoded device
which fails on NVMe and other layouts; update the grub-installer/bootdev preseed
value from the literal "/dev/sda" to "default" so the installer auto-detects the
first boot disk (change the line containing d-i grub-installer/bootdev string
/dev/sda to use string default).
In `@Makefile`:
- Around line 37-39: The Makefile clean target is too destructive because it
runs docker system prune -f --volumes which removes unused volumes system-wide;
change the clean target to be project-scoped by either using docker-compose down
--volumes (or docker-compose -f docker-compose.yml down --volumes) to remove
only CyberPot containers/networks/volumes, or replace docker system prune with
docker system prune -f (no --volumes) and/or add an interactive confirmation
prompt before removing volumes; update the Makefile target name clean
accordingly to call the safer command.
🧹 Nitpick comments (8)
docker/tanner/tanner/Dockerfile (1)
80-80: Trailing whitespace and missing newline at end of file.The CMD line has a trailing space and the file appears to be missing a final newline. While not functionally impacting, these are minor style inconsistencies.
Additionally, consider using the exec form
CMD ["tanner"]which is the preferred Docker best practice as it ensures proper signal handling.🔧 Suggested fix
-CMD tanner +CMD ["tanner"]docker/log4pot/Dockerfile (1)
65-65: Consider adding a trailing newline.POSIX text files should end with a newline character. Some tools may behave unexpectedly without it. This is a minor formatting concern with no functional impact.
compose/standard.yml (1)
369-371:pull_policyhas no effect when usingbuildcontext.When the service is configured to build from a local Dockerfile rather than pull an image, the
pull_policydirective is ignored. Consider removing it for clarity or switching back to an image reference if the intent is to pull a pre-built image.Suggested fix
build: context: ./docker/honeyaml - pull_policy: ${CYBERPOT_PULL_POLICY} read_only: truedocker-build.sh (1)
59-65: Minor quoting inconsistency in version tag assignment.Line 62 places quotes outside the command substitution while lines 60 and 64 use a consistent pattern. Consider aligning for readability.
Suggested fix
if [ -n "$VERSION_TAG_ARG" ]; then VERSION_TAG=":$VERSION_TAG_ARG" elif [ -f "version" ]; then - VERSION_TAG=":"$(cat version | tr -d '[:space:]') + VERSION_TAG=":$(cat version | tr -d '[:space:]')" else VERSION_TAG=":latest" fiMakefile (1)
29-35: Consider usingdocker compose(plugin) instead ofdocker-compose(standalone).The standalone
docker-composecommand is legacy. Modern Docker installations use thedocker composeplugin syntax. This could fail on systems without the standalone binary installed.Suggested fix
up: `@echo` "Starting Docker Compose services..." - docker-compose -f docker-compose.yml up -d + docker compose -f docker-compose.yml up -d down: `@echo` "Stopping Docker Compose services..." - docker-compose -f docker-compose.yml down + docker compose -f docker-compose.yml downiso-build/build.sh (3)
15-15: Unused variableISO_LABEL.
ISO_LABELis defined but never used. Either remove it or add it to the xorriso command with-V "${ISO_LABEL}".💡 Proposed fix to use the label
xorriso -as mkisofs \ -r -J -joliet-long \ + -V "${ISO_LABEL}" \ -b isolinux/isolinux.bin \
175-175: Avoidls | greppattern; use glob instead.Parsing
lsoutput is fragile with non-alphanumeric filenames. Use a glob or find instead.♻️ Proposed fix
-KERNEL_VERSION=$(ls "${CHROOT_DIR}/boot/" | grep "vmlinuz-" | sed 's/vmlinuz-//') +KERNEL_VERSION=$(basename "${CHROOT_DIR}"/boot/vmlinuz-* | sed 's/vmlinuz-//')
62-68: Tool installation installs all packages regardless of which is missing.The loop checks each tool individually but installs all packages (
debootstrap xorriso squashfs-tools) if any one is missing. This is fine functionally but could be more efficient by only installing what's needed, or simplified by removing the loop.💡 Simplified approach
# Check for required tools -for tool in debootstrap xorriso mksquashfs; do - if ! command_exists "$tool"; then - echo "Installing required tool: $tool" - apt-get update - apt-get install -y --no-install-recommends debootstrap xorriso squashfs-tools - fi -done +MISSING_TOOLS=0 +for tool in debootstrap xorriso mksquashfs; do + command_exists "$tool" || MISSING_TOOLS=1 +done +if [ "$MISSING_TOOLS" -eq 1 ]; then + echo "Installing required tools..." + apt-get update + apt-get install -y --no-install-recommends debootstrap xorriso squashfs-tools +fi
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (2)
docker/dionaea/dist/cpu_check.pyis excluded by!**/dist/**docker/dionaea/dist/etc/dionaea.cfgis excluded by!**/dist/**
📒 Files selected for processing (60)
.envCHANGELOG.mdMakefileREADME.mdcompose/standard.ymldocker-build.shdocker-compose.ymldocker/adbhoney/docker-compose.ymldocker/ciscoasa/docker-compose.ymldocker/citrixhoneypot/docker-compose.ymldocker/conpot/docker-compose.ymldocker/ddospot/docker-compose.ymldocker/deprecated/cyberchef/Dockerfiledocker/deprecated/cyberchef/docker-compose.ymldocker/deprecated/honeysap/docker-compose.ymldocker/deprecated/rdpy/docker-compose.ymldocker/dicompot/docker-compose.ymldocker/dionaea/Dockerfiledocker/dionaea/docker-compose.ymldocker/elasticpot/docker-compose.ymldocker/elk/docker-compose.ymldocker/elk/kibana/Dockerfiledocker/elk/kibana/docker-compose.ymldocker/elk/map/Dockerfiledocker/elk/map/docker-compose.ymldocker/endlessh/docker-compose.ymldocker/ewsposter/Dockerfiledocker/fatt/docker-compose.ymldocker/glutton/docker-compose.ymldocker/h0neytr4p/docker-compose.ymldocker/hellpot/docker-compose.ymldocker/heralding/docker-compose.ymldocker/honeypots/docker-compose.ymldocker/ipphoney/docker-compose.ymldocker/log4pot/Dockerfiledocker/log4pot/docker-compose.ymldocker/mailoney/docker-compose.ymldocker/medpot/Dockerfiledocker/medpot/docker-compose.ymldocker/nginx/Dockerfiledocker/nginx/builder/cyberchef/Dockerfiledocker/nginx/builder/esvue/Dockerfiledocker/nginx/docker-compose.ymldocker/p0f/docker-compose.ymldocker/redishoneypot/Dockerfiledocker/redishoneypot/docker-compose.ymldocker/sentrypeer/Dockerfile.alpine.keepdocker/sentrypeer/docker-compose.ymldocker/spiderfoot/docker-compose.ymldocker/suricata/docker-compose.ymldocker/tanner/docker-compose.ymldocker/tanner/snare/Dockerfiledocker/tanner/tanner/Dockerfileinstall.shinstaller/install/cyberpot.ymliso-build/build.shiso-build/custom-scripts/cyberpot-first-boot.serviceiso-build/custom-scripts/cyberpot-first-boot.shiso-build/preseed.cfgupdate.sh
🧰 Additional context used
🪛 checkmake (0.2.2)
Makefile
[warning] 1-1: Missing required phony target "test"
(minphony)
🪛 Shellcheck (0.11.0)
iso-build/build.sh
[warning] 15-15: ISO_LABEL appears unused. Verify use (or export if used externally).
(SC2034)
[warning] 175-175: Don't use ls | grep. Use a glob or a for loop with a condition to allow non-alphanumeric filenames.
(SC2010)
🔇 Additional comments (60)
docker/p0f/docker-compose.yml (1)
11-11: LGTM!Image tag bump to 24.04.1 is consistent with the PR's version update objectives.
docker/ciscoasa/docker-compose.yml (1)
20-20: LGTM!Image tag bump to 24.04.1 aligns with the version update across other services.
docker/tanner/snare/Dockerfile (1)
54-54: LGTM!Trailing newline removal is a non-functional formatting change. The CMD instruction remains unchanged and functional.
docker/redishoneypot/docker-compose.yml (1)
17-17: LGTM!Image tag bump to 24.04.1 is consistent with the PR's version update objectives.
docker/glutton/docker-compose.yml (1)
16-16: Registry migration and version bump.This service migrates to
ghcr.ioregistry in addition to the version bump from24.04to24.04.1. Note that some other services (e.g., p0f, ciscoasa, redishoneypot, nginx) remain on thekhulnasoft(Docker Hub) registry, indicating a phased migration across the project. Verify the image is published and accessible at the new registry location.docker/deprecated/honeysap/docker-compose.yml (1)
17-17: LGTM!Image tag bump to 24.04.1 is consistent with the broader release update across the repository.
docker/nginx/docker-compose.yml (1)
23-23: LGTM!Image tag bump to 24.04.1 aligns with the coordinated version update across services.
docker/suricata/docker-compose.yml (1)
18-18: LGTM!Image tag bump to 24.04.1 is consistent with the release update.
docker/spiderfoot/docker-compose.yml (1)
17-17: LGTM!Image tag bump to 24.04.1 is consistent with the coordinated version update.
docker/heralding/docker-compose.yml (1)
34-34: LGTM!The image tag update to
24.04.1is consistent with the broader version bump across the repository.docker/sentrypeer/docker-compose.yml (1)
25-25: LGTM!The image tag update to
24.04.1aligns with the repository-wide version bump.docker/honeypots/docker-compose.yml (1)
50-50: LGTM!The image tag update to
24.04.1is consistent with the broader version bump pattern in this PR.docker/nginx/Dockerfile (1)
1-1: No action needed—Alpine 3.23 is a stable, released version (December 3, 2025) and is suitable for use.Likely an incorrect or invalid review comment.
docker/fatt/docker-compose.yml (1)
17-17: The fatt image tag is consistent with other services in this PR. While some services (cowrie, conpot, dionaea) use24.04.1, others (elasticpot, ddospot) also use24.04like fatt. No action needed.docker/deprecated/rdpy/docker-compose.yml (1)
25-25: LGTM!Image tag update to 24.04.1 is consistent with the broader version bump across the repository.
docker/sentrypeer/Dockerfile.alpine.keep (1)
1-1: LGTM!The change from
astoASfor the multi-stage build alias aligns with Docker's recommended convention for consistency and readability.docker/log4pot/docker-compose.yml (1)
27-27: No functional change detected.The volume configuration remains identical. This appears to be a formatting-only change.
docker/ipphoney/docker-compose.yml (1)
17-17: LGTM!Image tag update to 24.04.1 is consistent with the version bump pattern. Note that this service uses
khulnasoft/(Docker Hub) while some other services in this PR useghcr.io/khulnasoft/. Verify this registry difference is intentional based on where images are published.docker/elk/map/Dockerfile (1)
17-17: The repository URL change fromkhulnasoft-labtokhulnasoftorganization is valid. The repositoryhttps://github.com/khulnasoft/cyberpot-attack-mapexists and contains the2.2.6tag.docker/hellpot/docker-compose.yml (1)
17-17: LGTM!Image tag bump to
24.04.1is consistent with the PR-wide version update.docker/mailoney/docker-compose.yml (1)
20-20: LGTM!Image tag bump to
24.04.1aligns with the coordinated version update across services.docker/deprecated/cyberchef/docker-compose.yml (1)
17-17: LGTM!Image tag bump to
24.04.1is appropriate. Since this service is already deprecated, the legacyversion: '2.3'compose format is acceptable.docker/adbhoney/docker-compose.yml (1)
17-17: LGTM!Image tag bump to
24.04.1is consistent with the coordinated version update.docker/tanner/docker-compose.yml (1)
116-117: LGTM - formatting change only.The
depends_onindentation adjustment doesn't affect functionality. The dependency ontanneris correctly maintained.One observation: this file uses
khulnasoft/image references (e.g., line 17, 33, 49, etc.) while other files in this PR are migrating toghcr.io/khulnasoft/. Consider whether this inconsistency is intentional.docker/dicompot/docker-compose.yml (1)
21-21: LGTM - Registry migration to ghcr.io.The image reference update from Docker Hub to GitHub Container Registry is consistent with the broader PR pattern. Ensure the image
ghcr.io/khulnasoft/dicompot:24.04is published and accessible before deploying.docker/endlessh/docker-compose.yml (1)
17-17: LGTM - Registry migration to ghcr.io.Consistent registry update aligning with the broader PR changes.
docker/redishoneypot/Dockerfile (1)
1-1: LGTM - Style normalization.The
ASkeyword is case-insensitive in Docker, but uppercase is the documented convention. This change aligns with Docker best practices.docker/elasticpot/docker-compose.yml (1)
17-17: LGTM - Registry migration to ghcr.io.Consistent registry update aligning with the broader PR changes.
docker/medpot/docker-compose.yml (1)
17-20: LGTM!The image registry migration to
ghcr.ioand version bump to24.04.1are consistent with the PR objectives and other updated services.docker/conpot/docker-compose.yml (5)
62-62: Duplicate of registry concern above.Same registry inconsistency applies to
conpot_IEC104.
85-85: Duplicate of registry concern above.Same registry inconsistency applies to
conpot_guardian_ast.
108-108: Duplicate of registry concern above.Same registry inconsistency applies to
conpot_ipmi.
132-132: Duplicate of registry concern above.Same registry inconsistency applies to
conpot_kamstrup_382.
38-38: Registry inconsistency: conpot services remain on Docker Hub while other services migrated to ghcr.io.Conpot services use
khulnasoft/conpot:24.04.1(Docker Hub), while ddospot, medpot, and dionaea have been migrated toghcr.io/khulnasoft/. The conpot image does not exist on ghcr.io. This is part of a broader pattern in the migration—approximately 20 services remain on Docker Hub while 22 have been moved to ghcr.io. Confirm whether conpot is intentionally excluded from the migration or if it should be included once the image is available on ghcr.io.docker/dionaea/docker-compose.yml (2)
34-34: LGTM!The image registry migration to
ghcr.ioand version bump to24.04.1are correct and consistent with the PR objectives.
44-44: No functional change.The volume mapping remains unchanged; only whitespace was adjusted.
docker/ddospot/docker-compose.yml (1)
21-21: Version tag inconsistency.The ddospot image uses version
24.04while medpot, dionaea, and conpot are on24.04.1. Confirm whether this version should be updated to24.04.1for consistency with other recently bumped services, or if staying on24.04is intentional.docker/deprecated/cyberchef/Dockerfile (1)
1-1: Base images are end-of-life—consider updating if this service remains active.The
node:10.24.1-alpine3.11andalpine:3.15base images are both past their end-of-life dates (April 2021 and November 2023 respectively) and contain known security vulnerabilities. While this file is in the deprecated folder, if the service is still in use, these images should be updated to supported versions.docker/medpot/Dockerfile (2)
20-20: LGTM! Module replacement for deprecated package.The
go mod edit -replacedirective correctly redirects the deprecatedgithub.com/go-ini/initogopkg.in/ini.v1@v1.67.0, which is the recommended migration path for this package.
1-1: No action needed. Thegolang:1.24-alpineimage is valid—Go 1.24 was released on February 11, 2025 and is available on Docker Hub.Likely an incorrect or invalid review comment.
docker/h0neytr4p/docker-compose.yml (1)
18-18: LGTM!Image tag updated to
24.04.1and migrated toghcr.ioregistry, consistent with the broader PR changes.docker/nginx/builder/cyberchef/Dockerfile (1)
1-2: LGTM!Updated base image from Node 17 to Node 18 LTS. The commented-out old version provides helpful context for the change.
docker/citrixhoneypot/docker-compose.yml (1)
17-17: Version bump is correct, but note the registry inconsistency.The image tag is correctly updated to
24.04.1. However,citrixhoneypotremains on Docker Hub (khulnasoft/...) whileh0neytr4pand many other services have migrated to GitHub Container Registry (ghcr.io/khulnasoft/...). Depending on whether a full registry migration is planned, this service may need to be updated to maintain consistency.docker/elk/kibana/Dockerfile (2)
57-57: LGTM!The CMD directive correctly starts Kibana with the expected binary path.
25-26: No action required; the glibc path is correct for Kibana 9.x.Kibana 9.2.3 (the version in this Dockerfile) maintains the bundled Node directory structure at
/usr/share/kibana/node/glibc-217/bin/node. The symlink replacement at lines 25–26 is valid and should work without issues.Likely an incorrect or invalid review comment.
docker/elk/kibana/docker-compose.yml (1)
13-13: LGTM!The image reference is correctly updated to the new GHCR registry with the 24.04.1 tag, consistent with the PR's migration objectives.
docker/elk/docker-compose.yml (1)
25-25: LGTM!All service images are consistently updated to use the
ghcr.io/khulnasoft/<service>:24.04.1registry and tag format. The configuration maintains good security practices with localhost-only port bindings and appropriate resource limits.Also applies to: 41-41, 53-53, 66-66, 80-80, 92-94
docker/nginx/builder/esvue/Dockerfile (2)
14-19: LGTM on the npm migration.The switch from Yarn to npm is clean. The workflow correctly copies both
package.jsonandpackage-lock.jsonbefore runningnpm install, ensuring reproducible builds.
23-24: LGTM!The multi-stage build correctly exports only the built artifact (
esvue.tgz) using a scratch image, minimizing the final output size.docker/dionaea/Dockerfile (2)
126-126: LGTM!The CMD directive correctly starts dionaea with appropriate user/group settings and configuration file path.
16-18: HTTPS and ca-certificates correctly implemented.Adding
ca-certificatesbefore using wget with HTTPS is the correct approach. The migration to HTTPS for snapshot.debian.org URLs improves supply chain security and the fixed snapshot timestamp (20170317T220000Z) ensures reproducible builds.The libemu packages (0.2.0+git20120122-1.2+b1) have no known CVEs, but periodic checks for newer versions or security advisories remain a good practice.
installer/install/cyberpot.yml (1)
340-348: LGTM! RedHat Docker repository task added correctly.The RHEL-specific Docker repository configuration follows the same pattern as Fedora and AlmaLinux/Rocky, using the official Docker repository URL for RHEL.
docker-compose.yml (1)
856-856: LGTM - formatting change only.The Spiderfoot volume mount configuration appears unchanged in substance. The volume mapping is correctly configured.
README.md (1)
141-141: LGTM - repository reference updated.The CyberPot-Attack-Map link correctly updated to the new repository location under
khulnasoftorganization, consistent with other changes in this PR.iso-build/custom-scripts/cyberpot-first-boot.service (1)
1-13: Service configuration is correct with proper cleanup.The systemd service file is well-configured. Verification confirms that
/root/cyberpot-first-boot.shproperly handles one-time execution by disabling the service (systemctl disable), removing the service file, removing the script itself, and rebooting—ensuring the service won't re-run on subsequent boots.update.sh (1)
170-171: The concern is invalid. The script correctly pulls and removes different image versions.The script pulls images with tag
24.04(fromCYBERPOT_VERSION=24.04in.env) and removes images with older tags (:24.04.1and:dev). Since these are different tags, the removal does not affect the newly pulled images. The logic correctly cleans up old versions after upgrading.iso-build/custom-scripts/cyberpot-first-boot.sh (1)
18-25: Verify heredoc input matches install.sh prompts.The heredoc provides pre-configured answers to the installer. Ensure these inputs (
y,h,cyberpotx3,y) align with the current install.sh prompt sequence. If prompts change, this automation will break silently or provide incorrect answers.docker/elk/map/docker-compose.yml (1)
12-12: LGTM!Image version bumps to
24.04.1are consistent across all services (map_redis,map_web,map_data).Also applies to: 26-26, 40-42
install.sh (2)
193-193: LGTM!The
cpcommands consistently use relative paths (compose/*.ymltodocker-compose.yml), aligning with the shift to current-directory-based operation.Also applies to: 200-200, 208-208, 215-215, 222-222, 229-229
311-311: LGTM!Docker compose command updated to use relative path, consistent with other changes.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
| # Multiple users are possible: | ||
| # WEB_USER=dHNlYzokYXByMSRYUnE2SC5rbiRVRjZQM1VVQmJVNWJUQmNmSGRuUFQxCgo= dHNlYzokYXByMSR6VUFHVWdmOCRROXI3a09CTjFjY3lCeU1DTloyanEvCgo= | ||
| WEB_USER= | ||
| WEB_USER=Y3liZXJwb3Q6JGFwcjEkRnJJN0Y4Uk8kUFNBLklsWmpnWHBmSnRPVUI2czc1Lg== |
There was a problem hiding this comment.
Hardcoded credentials should not be committed.
The WEB_USER contains what appears to be default credentials (cyberpot:$apr1$...). Committing credentials to version control poses a security risk. Consider:
- Leaving this empty as the default (as the comments suggest on lines 8-9)
- Adding this value to
.gitignoreor using a separate.env.localfile
Suggested fix
-WEB_USER=Y3liZXJwb3Q6JGFwcjEkRnJJN0Y4Uk8kUFNBLklsWmpnWHBmSnRPVUI2czc1Lg==
+WEB_USER=📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| WEB_USER=Y3liZXJwb3Q6JGFwcjEkRnJJN0Y4Uk8kUFNBLklsWmpnWHBmSnRPVUI2czc1Lg== | |
| WEB_USER= |
🤖 Prompt for AI Agents
In @.env at line 15, The WEB_USER environment variable contains hardcoded
credentials; remove the encoded value for WEB_USER and replace it with an empty
value or a non-secret placeholder, move the actual credential into a local-only
env file (e.g., use a separate env file that is not committed) and ensure that
local secret env files are ignored by adding them to .gitignore; also rotate the
exposed credential. Reference: update the WEB_USER entry to avoid committing
secrets.
|
|
||
| # CyberPot Version Tag | ||
| CYBERPOT_VERSION=24.04.1 | ||
| CYBERPOT_VERSION=24.04 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Check the .env file at line 152 and surrounding context
if [ -f .env ]; then
echo "=== .env file content (lines 145-160) ==="
sed -n '145,160p' .env
else
echo ".env file not found"
fiRepository: khulnasoft/cyberpot
Length of output: 924
🏁 Script executed:
# Search for update.sh and check version references
if [ -f update.sh ]; then
echo "=== update.sh - searching for version references ==="
grep -n "24.04\|CYBERPOT_VERSION\|version" update.sh | head -20
else
echo "update.sh not found, searching for it..."
find . -name "update.sh" -type f 2>/dev/null
fiRepository: khulnasoft/cyberpot
Length of output: 782
🏁 Script executed:
# Search for version references across the codebase
echo "=== Searching for CYBERPOT_VERSION references ==="
rg "CYBERPOT_VERSION|24\.04" --no-heading -n | head -30Repository: khulnasoft/cyberpot
Length of output: 2354
Version mismatch with other files in this PR.
CYBERPOT_VERSION=24.04 in .env conflicts with update.sh which sets myMASTERVERSION="24.04.1" as the target version. The env.example file also specifies 24.04.1. This mismatch will cause docker-compose to pull images with the wrong version tag.
Proposed fix
-CYBERPOT_VERSION=24.04
+CYBERPOT_VERSION=24.04.1📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| CYBERPOT_VERSION=24.04 | |
| CYBERPOT_VERSION=24.04.1 |
🤖 Prompt for AI Agents
In @.env at line 152, The CYBERPOT_VERSION value in .env is inconsistent with
update.sh's myMASTERVERSION and env.example; change the CYBERPOT_VERSION
variable in the .env file from "24.04" to "24.04.1" so it matches
myMASTERVERSION="24.04.1" in update.sh and the version in env.example to ensure
docker-compose pulls the correct image tag.
| - To avoid confusion and downtime, the `24.04.1` tag for Docker images has been introduced. | ||
| - **Important**: Actively update CyberPot as described in the [README](https://github.com/khulnasoft/cyberpot/blob/master/README.md). | ||
| - **Deprecation Notice**: The `24.04` tagged images will no longer be maintained and will be removed by **2025-01-31**. | ||
| - **Deprecation Notice**: The `24.04.1` tagged images will no longer be maintained and will be removed by **2025-01-31**. |
There was a problem hiding this comment.
Deprecation notice references the wrong version.
The notice states that 24.04.1 images will be deprecated by 2025-01-31, but this PR is introducing version 24.04.1 as the new release. The deprecation notice should reference the old version (likely 24.04 or earlier) that is being superseded.
Suggested fix
-- **Deprecation Notice**: The `24.04.1` tagged images will no longer be maintained and will be removed by **2025-01-31**.
+- **Deprecation Notice**: The `24.04` tagged images will no longer be maintained and will be removed by **2025-01-31**. 📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - **Deprecation Notice**: The `24.04.1` tagged images will no longer be maintained and will be removed by **2025-01-31**. | |
| - **Deprecation Notice**: The `24.04` tagged images will no longer be maintained and will be removed by **2025-01-31**. |
🤖 Prompt for AI Agents
In `@CHANGELOG.md` at line 32, The deprecation line in CHANGELOG.md incorrectly
names the new release (24.04.1) as being removed; update the notice to reference
the superseded old version (e.g., change "24.04.1" to "24.04") so it reads that
the old 24.04 images will be removed by 2025-01-31, and double-check the
surrounding changelog entries mention 24.04.1 as the new release for
consistency.
| image: khulnasoft/kibana:24.04.1 | ||
| pull_policy: ${CYBERPOT_PULL_POLICY} |
There was a problem hiding this comment.
Inconsistent image reference: Kibana uses hardcoded image while other services use variables.
All other services reference images via ${CYBERPOT_REPO}/service:${CYBERPOT_VERSION}, but Kibana is hardcoded to khulnasoft/kibana:24.04.1. This breaks consistency and will require manual updates when the version changes.
Suggested fix
- image: khulnasoft/kibana:24.04.1
+ image: ${CYBERPOT_REPO}/kibana:${CYBERPOT_VERSION}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| image: khulnasoft/kibana:24.04.1 | |
| pull_policy: ${CYBERPOT_PULL_POLICY} | |
| image: ${CYBERPOT_REPO}/kibana:${CYBERPOT_VERSION} | |
| pull_policy: ${CYBERPOT_PULL_POLICY} |
🤖 Prompt for AI Agents
In `@compose/standard.yml` around lines 710 - 711, Kibana's image is hardcoded as
"khulnasoft/kibana:24.04.1" which breaks consistency; change the image value for
the Kibana service to use the existing repo/version variables (e.g., replace the
hardcoded string with "${CYBERPOT_REPO}/kibana:${CYBERPOT_VERSION}") so it
follows the same pattern as other services and continues to use the
CYBERPOT_PULL_POLICY for pulls.
| find docker -name Dockerfile | while read -r dockerfile; do | ||
| dir=$(dirname "$dockerfile") | ||
| # Exclude deprecated and builder directories | ||
| if [[ "$dir" == *"deprecated"* || "$dir" == *"builder"* ]]; then | ||
| echo "Skipping build for Dockerfile in $dir" | ||
| continue | ||
| fi | ||
| # Get the path relative to the 'docker' directory | ||
| relative_path=${dir#docker/} | ||
| # Replace slashes with hyphens for the tag | ||
| image_name="${PREFIX}/$(echo "$relative_path" | tr '/' '-')" | ||
| tag="${image_name}${VERSION_TAG}" | ||
| echo "Building Docker image in $dir with tag $tag" | ||
| (cd "$dir" && docker build -t "$tag" .) | ||
| done | ||
|
|
||
| echo "All Docker images built successfully." |
There was a problem hiding this comment.
Build failures won't cause script exit due to subshell from pipe.
The find ... | while read pattern runs the while loop in a subshell, so set -e won't cause the script to exit if docker build fails. The success message on line 90 will print regardless of build outcomes.
Suggested fix using process substitution
-find docker -name Dockerfile | while read -r dockerfile; do
+failed=0
+while read -r dockerfile; do
dir=$(dirname "$dockerfile")
# Exclude deprecated and builder directories
if [[ "$dir" == *"deprecated"* || "$dir" == *"builder"* ]]; then
echo "Skipping build for Dockerfile in $dir"
continue
fi
# Get the path relative to the 'docker' directory
relative_path=${dir#docker/}
# Replace slashes with hyphens for the tag
image_name="${PREFIX}/$(echo "$relative_path" | tr '/' '-')"
tag="${image_name}${VERSION_TAG}"
echo "Building Docker image in $dir with tag $tag"
- (cd "$dir" && docker build -t "$tag" .)
-done
+ if ! (cd "$dir" && docker build -t "$tag" .); then
+ echo "ERROR: Failed to build $tag" >&2
+ failed=1
+ fi
+done < <(find docker -name Dockerfile)
-echo "All Docker images built successfully."
+if [ "$failed" -eq 0 ]; then
+ echo "All Docker images built successfully."
+else
+ echo "Some Docker images failed to build." >&2
+ exit 1
+fi📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| find docker -name Dockerfile | while read -r dockerfile; do | |
| dir=$(dirname "$dockerfile") | |
| # Exclude deprecated and builder directories | |
| if [[ "$dir" == *"deprecated"* || "$dir" == *"builder"* ]]; then | |
| echo "Skipping build for Dockerfile in $dir" | |
| continue | |
| fi | |
| # Get the path relative to the 'docker' directory | |
| relative_path=${dir#docker/} | |
| # Replace slashes with hyphens for the tag | |
| image_name="${PREFIX}/$(echo "$relative_path" | tr '/' '-')" | |
| tag="${image_name}${VERSION_TAG}" | |
| echo "Building Docker image in $dir with tag $tag" | |
| (cd "$dir" && docker build -t "$tag" .) | |
| done | |
| echo "All Docker images built successfully." | |
| failed=0 | |
| while read -r dockerfile; do | |
| dir=$(dirname "$dockerfile") | |
| # Exclude deprecated and builder directories | |
| if [[ "$dir" == *"deprecated"* || "$dir" == *"builder"* ]]; then | |
| echo "Skipping build for Dockerfile in $dir" | |
| continue | |
| fi | |
| # Get the path relative to the 'docker' directory | |
| relative_path=${dir#docker/} | |
| # Replace slashes with hyphens for the tag | |
| image_name="${PREFIX}/$(echo "$relative_path" | tr '/' '-')" | |
| tag="${image_name}${VERSION_TAG}" | |
| echo "Building Docker image in $dir with tag $tag" | |
| if ! (cd "$dir" && docker build -t "$tag" .); then | |
| echo "ERROR: Failed to build $tag" >&2 | |
| failed=1 | |
| fi | |
| done < <(find docker -name Dockerfile) | |
| if [ "$failed" -eq 0 ]; then | |
| echo "All Docker images built successfully." | |
| else | |
| echo "Some Docker images failed to build." >&2 | |
| exit 1 | |
| fi |
🤖 Prompt for AI Agents
In `@docker-build.sh` around lines 74 - 90, The find | while read loop runs in a
subshell so failures in the docker build inside that loop won't trigger script
exit; replace the pipeline with process substitution (use while read -r
dockerfile; do ... done < <(find docker -name Dockerfile ...) or use find
-print0 with while IFS= read -r -d '' dockerfile; do ... done < <(find ...
-print0) to run the loop in the main shell, and after the (cd "$dir" && docker
build -t "$tag" .) check the build exit status (or simply let set -e handle it
in the main shell) and exit non-zero on failure so the final echo "All Docker
images built successfully." only runs when all builds succeed; keep references
to variables image_name, tag, relative_path and the docker build invocation so
you update the correct loop.
| mount --bind /dev "${CHROOT_DIR}/dev" | ||
| mount -t proc proc "${CHROOT_DIR}/proc" | ||
| mount -t sysfs sysfs "${CHROOT_DIR}/sys" |
There was a problem hiding this comment.
Missing cleanup trap for mounted filesystems.
If the script fails between mounting (lines 86-88) and unmounting (lines 148-150), the pseudo-filesystems remain mounted, which can cause issues. Add a trap to ensure cleanup.
🔒 Proposed fix
+# Cleanup function for mounts
+cleanup_mounts() {
+ echo "Cleaning up mounts..."
+ umount "${CHROOT_DIR}/dev" 2>/dev/null || true
+ umount "${CHROOT_DIR}/proc" 2>/dev/null || true
+ umount "${CHROOT_DIR}/sys" 2>/dev/null || true
+}
+trap cleanup_mounts EXIT
+
# Mount pseudo-filesystems
mount --bind /dev "${CHROOT_DIR}/dev"
mount -t proc proc "${CHROOT_DIR}/proc"
mount -t sysfs sysfs "${CHROOT_DIR}/sys"Also applies to: 148-150
🤖 Prompt for AI Agents
In `@iso-build/build.sh` around lines 86 - 88, The mounts for /dev, /proc and /sys
under CHROOT_DIR are not protected by a cleanup trap, so if the script exits
early the pseudo-filesystems remain mounted; add a cleanup function (e.g.,
cleanup_chroot) that checks for and unmounts "${CHROOT_DIR}/dev",
"${CHROOT_DIR}/proc" and "${CHROOT_DIR}/sys" (use safe unmount checks and
fallbacks like umount -l if necessary), register it with trap 'cleanup_chroot'
on EXIT ERR INT TERM, and call or skip it appropriately before the existing
unmount lines to ensure mounts added by the mount --bind and mount -t proc/sysfs
commands are always cleaned up.
| useradd -m -s /bin/bash tempuser | ||
| echo "tempuser:tempuser" | chpasswd | ||
| adduser tempuser sudo |
There was a problem hiding this comment.
Security concern: Temporary user with known password left behind on failure.
With set -e, if the installer fails, the script exits before cleanup (lines 27-35), leaving tempuser with the hardcoded password tempuser on the system. Consider using a trap to ensure cleanup on exit.
🔒 Proposed fix using trap for cleanup
# Exit on any error
set -e
+# Ensure cleanup on exit
+cleanup() {
+ if id tempuser &>/dev/null; then
+ userdel -r tempuser 2>/dev/null || true
+ fi
+}
+trap cleanup EXIT
+
echo "--- Starting CyberPot First Boot Installation ---"🤖 Prompt for AI Agents
In `@iso-build/custom-scripts/cyberpot-first-boot.sh` around lines 13 - 15, Add a
cleanup function (e.g., cleanup_tempuser) and install a trap before creating the
temporary account so the user is always removed on exit/failure: define
cleanup_tempuser to check for the existence of user "tempuser" and delete it
with its home (e.g., deluser --remove-home or userdel -r), set trap
'cleanup_tempuser' EXIT right before the useradd/chpasswd/adduser lines, and if
you need to retain the account on successful completion remove or clear the trap
(trap - EXIT) after the successful path; ensure the cleanup function is
idempotent and safe to call even if the user was never created.
| d-i passwd/root-login boolean true | ||
| d-i passwd/root-password password cyberpot | ||
| d-i passwd/root-password-again password cyberpot | ||
| d-i passwd/make-user boolean true | ||
| d-i passwd/user-fullname string CyberPot User | ||
| d-i passwd/username string cyberpot | ||
| d-i passwd/user-password password cyberpot | ||
| d-i passwd/user-password-again password cyberpot | ||
| d-i user-setup/allow-password-weak boolean true |
There was a problem hiding this comment.
Security concern: Hardcoded default passwords for root and user accounts.
Both root and user passwords are set to cyberpot. While this enables unattended installation, ensure documentation clearly states that users must change these passwords immediately after installation, or implement a forced password change on first login.
🤖 Prompt for AI Agents
In `@iso-build/preseed.cfg` around lines 21 - 29, Remove hardcoded plaintext
passwords set by d-i passwd/root-password and d-i passwd/user-password in
preseed.cfg; instead either (A) remove those lines and require interactive
password entry or use a hashed password mechanism, and update documentation to
instruct users to change passwords immediately after install, or (B) keep
automated setup but add a post-install step (via late_command) that forces
password reset on first login (e.g., run chage -d 0 for the 'root' and
'cyberpot' user) and remove/avoid user-setup/allow-password-weak enabling
insecure defaults; ensure the chosen approach updates the README/installation
docs to state the enforced password-change behavior.
| # GRUB installation | ||
| d-i grub-installer/only_debian boolean true | ||
| d-i grub-installer/with_other_os boolean true | ||
| d-i grub-installer/bootdev string /dev/sda |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
debian preseed grub-installer bootdev automatic detection nvme
💡 Result:
Yes — set grub-installer/bootdev to "default" in your preseed so the installer uses the automatically-detected first boot disk (works for NVMe like /dev/nvme0n1). Example line:
grub-installer/bootdev string default
This was added to debian-installer to let preseeds pick the default-detected disk and skip the device prompt. [1][2][3]
Sources:
- Debian bug/changelog showing support for "default" in grub-installer/bootdev. [1][2]
- Debian preseeding docs (general preseeding/auto-install reference). [3]
Replace hardcoded /dev/sda with "default" for bootdev detection.
The hardcoded /dev/sda bootdev will fail on systems with NVMe drives (/dev/nvme0n1) and other storage configurations. Use string default instead to let the installer automatically detect the first boot disk, which works across all storage types.
Suggested fix
-d-i grub-installer/bootdev string /dev/sda
+d-i grub-installer/bootdev string default
🤖 Prompt for AI Agents
In `@iso-build/preseed.cfg` at line 52, The preseed entry sets
grub-installer/bootdev to a hardcoded device which fails on NVMe and other
layouts; update the grub-installer/bootdev preseed value from the literal
"/dev/sda" to "default" so the installer auto-detects the first boot disk
(change the line containing d-i grub-installer/bootdev string /dev/sda to use
string default).
Makefile
Outdated
| clean: down | ||
| @echo "Cleaning up Docker system..." | ||
| docker system prune -f --volumes |
There was a problem hiding this comment.
clean target is destructive: removes ALL unused Docker volumes system-wide.
docker system prune -f --volumes will remove unused volumes from all projects on the system, not just CyberPot. This could unintentionally delete data from other Docker projects.
Suggested safer alternative
clean: down
`@echo` "Cleaning up Docker system..."
- docker system prune -f --volumes
+ docker system prune -f
+ `@echo` "Note: Run 'docker volume prune' manually if you want to remove unused volumes."Alternatively, if volume cleanup is essential, consider warning the user or targeting only CyberPot volumes by naming convention.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| clean: down | |
| @echo "Cleaning up Docker system..." | |
| docker system prune -f --volumes | |
| clean: down | |
| `@echo` "Cleaning up Docker system..." | |
| docker system prune -f | |
| `@echo` "Note: Run 'docker volume prune' manually if you want to remove unused volumes." |
🤖 Prompt for AI Agents
In `@Makefile` around lines 37 - 39, The Makefile clean target is too destructive
because it runs docker system prune -f --volumes which removes unused volumes
system-wide; change the clean target to be project-scoped by either using
docker-compose down --volumes (or docker-compose -f docker-compose.yml down
--volumes) to remove only CyberPot containers/networks/volumes, or replace
docker system prune with docker system prune -f (no --volumes) and/or add an
interactive confirmation prompt before removing volumes; update the Makefile
target name clean accordingly to call the safer command.
…d CI/CD - Refactored all Dockerfiles to use multi-stage builds, non-root users, and version pinning for enhanced security and efficiency. - Integrated a full monitoring stack including Prometheus, Grafana, and Alertmanager. - Implemented comprehensive CI/CD pipelines in .github/workflows for automated testing, security scanning, and deployment. - Enhanced installer security and reliability with Ansible improvements and credential management. - Added support for distributed edge sensors and horizontal scaling. - Reorganized project structure into src, scripts, and tests directories. - Updated documentation with advanced features, resource optimization, and implementation summaries.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| workflow_dispatch: | ||
|
|
||
| permissions: | ||
| contents: write |
Check notice
Code scanning / SonarCloud
Write permissions should be defined at the job level Low
|
|
||
| permissions: | ||
| contents: write | ||
| pull-requests: write |
Check notice
Code scanning / SonarCloud
Write permissions should be defined at the job level Low
| IMAGE_PREFIX: ghcr.io/${{ github.repository_owner }} | ||
|
|
||
| permissions: | ||
| contents: read |
Check notice
Code scanning / SonarCloud
Read permissions should be defined at the job level Low
|
|
||
| permissions: | ||
| contents: read | ||
| packages: write |
Check notice
Code scanning / SonarCloud
Write permissions should be defined at the job level Low
| type: string | ||
|
|
||
| permissions: | ||
| contents: write |
Check notice
Code scanning / SonarCloud
Write permissions should be defined at the job level Low
|
|
||
| permissions: | ||
| contents: write | ||
| packages: write |
Check notice
Code scanning / SonarCloud
Write permissions should be defined at the job level Low
| workflow_dispatch: | ||
|
|
||
| permissions: | ||
| contents: read |
Check notice
Code scanning / SonarCloud
Read permissions should be defined at the job level Low
|
|
||
| permissions: | ||
| contents: read | ||
| security-events: write |
Check notice
Code scanning / SonarCloud
Write permissions should be defined at the job level Low
| permissions: | ||
| contents: read | ||
| security-events: write | ||
| actions: read |
Check notice
Code scanning / SonarCloud
Read permissions should be defined at the job level Low
* feat: implement optimized .devcontainer and resource tuning for dev environment * feat: enhance Docker configurations, improve security, and update devcontainer setup * refactor: downgrade React to 18.3.1 and optimize AttackMap polling logic --------- Signed-off-by: KhulnaSoft bot <43526132+khulnasoft-bot@users.noreply.github.com>
* feat: implement optimized .devcontainer and resource tuning for dev environment * feat: enhance Docker configurations, improve security, and update devcontainer setup * refactor: downgrade React to 18.3.1 and optimize AttackMap polling logic * fix(docker): resolve dionaea build error and update service image registries --------- Signed-off-by: KhulnaSoft bot <43526132+khulnasoft-bot@users.noreply.github.com>
* feat: implement optimized .devcontainer and resource tuning for dev environment * feat: enhance Docker configurations, improve security, and update devcontainer setup * refactor: downgrade React to 18.3.1 and optimize AttackMap polling logic * fix(docker): resolve dionaea build error and update service image registries --------- Signed-off-by: KhulnaSoft bot <43526132+khulnasoft-bot@users.noreply.github.com>
|
2 participants
Summary by CodeRabbit
New Features
Updates
✏️ Tip: You can customize this high-level summary in your review settings.