test/docker_tests/configurations/mount-tests/docker-compose.mount-test.api_no-mount.yml (1)

38-40: Same tmpfs ownership concern as db_ramdisk configuration.

The removal of explicit uid/gid from tmpfs mounts follows the same pattern as other mount test configurations. Refer to the verification comment on docker-compose.mount-test.db_ramdisk.yml regarding tmpfs accessibility with PUID/PGID.

test/docker_tests/configurations/mount-tests/docker-compose.mount-test.active_config_no-mount.yml (1)

16-16: Same tmpfs ownership concern as other mount test configurations.

The CHOWN capability addition and mode=1700 tmpfs specification have the same implications as in other mount test configurations: the tmpfs mount defaults to root:root ownership and requires explicit chowning in the startup sequence for the application user to access it after privilege drop.

Also applies to: 34-34

test/docker_tests/configurations/mount-tests/docker-compose.mount-test.api_mounted.yml (1)

16-16: Same tmpfs ownership concern as other mount test configurations.

The CHOWN capability addition and mode=1700 tmpfs specifications follow the same pattern as other mount test configurations, with the same requirement that startup scripts must chown these tmpfs mounts for non-root user access.

Also applies to: 42-44

test/docker_tests/configurations/mount-tests/docker-compose.mount-test.active_config_mounted.yml (1)

16-16: Same tmpfs ownership concern as other mount test configurations.

The CHOWN capability addition and mode=1700 tmpfs specification follow the same pattern as other mount test configurations, requiring startup scripts to chown the tmpfs mount for non-root user access after privilege drop.

Also applies to: 38-38

install/production-filesystem/README.md (1)

89-89: Minor: Clarify PID 1 wording.

Line 89 states "becomes PID 1 and / in the Docker filesystem"—the second part is slightly ambiguous. Consider rephrasing to "becomes PID 1 (the root/init process) in the container" for clarity.

install/production-filesystem/services/start-php-fpm.sh (1)

35-37: Minor: Unusual output format for "done" message.

The echo -ne " done" outputs a leading space with no trailing newline, which seems intended to append to something. However, since line 29 already printed a complete message, this " done" appears on its own line when php-fpm exits. Consider either:

• Adding a newline: echo " done" (or echo "done")
• Removing the leading space if standalone output is intended

Also, -e is unnecessary here since there are no escape sequences.

🔎 Suggested fix

-echo -ne " done"
+echo "done"

install/production-filesystem/entrypoint.d/35-apply-conf-override.sh (1)

7-10: Consider validating NETALERTX_CONFIG is set for clearer diagnostics.

If NETALERTX_CONFIG is unset or empty, mkdir will fail but the error message may be unclear. Adding explicit validation would provide better diagnostics for this critical misconfiguration.

🔎 Proposed validation

 # Ensure config directory exists
+if [ -z "$NETALERTX_CONFIG" ]; then
+    >&2 echo "ERROR: NETALERTX_CONFIG environment variable is not set"
+    exit 1
+fi
+
 mkdir -p "$NETALERTX_CONFIG" || {
     >&2 echo "ERROR: Failed to create config directory $NETALERTX_CONFIG"
     exit 1
 }

test/docker_tests/configurations/mount-tests/docker-compose.mount-test.db_noread.yml (1)

15-15: Potentially unnecessary capabilities when not starting as root.

The configuration adds SETUID and SETGID capabilities (lines 19-20), which are typically used to drop privileges from root to a non-root user. However, since the container starts as user 20211:20211 (line 11) rather than root, these capabilities won't have any practical effect—only processes running as UID 0 can successfully use setuid/setgid system calls.

The CHOWN capability (line 15) appears necessary for the test's stated purpose of chowning /data/db, but SETUID/SETGID may be redundant in this configuration.

If this is intentional to test the capability handling logic regardless of effectiveness, consider adding a comment to clarify the rationale.

Also applies to: 19-20

test/docker_tests/configurations/mount-tests/docker-compose.mount-test.log_unwritable.yml (1)

53-53: Unused volume definition.

The test_system_services_active_config volume is defined but not mounted in this service. Line 44 uses tmpfs for /tmp/nginx/active-config instead.

If this volume definition is for consistency with other test configurations or template purposes, it's fine. Otherwise, consider removing it to keep the configuration minimal.

install/production-filesystem/entrypoint.d/15-mounts.py (1)

382-384: Consider using ASCII dash for terminal compatibility.

The HEAVY MINUS SIGN (➖) at line 384 may render inconsistently across terminals or logging systems. The TODO at lines 8-10 already notes plans to replace emoji indicators with plain text.

🔎 Suggested fix for consistent rendering

     CHECK_SYMBOL = "✅"
     CROSS_SYMBOL = "❌"
-    BLANK_SYMBOL = "➖"
+    BLANK_SYMBOL = "—"  # em-dash, or use "--" for pure ASCII

install/production-filesystem/entrypoint.d/30-mandatory-folders.sh (1)

31-31: The || true suppression is intentional design, but consider logging failures for observability.

This chmod error suppression is a consistent pattern across all production entrypoint scripts (30-mandatory-folders.sh, 25-first-run-db.sh, 05-data-migration.sh, root-entrypoint.sh), indicating deliberate handling for scenarios where chmod may fail due to container context constraints or filesystem limitations—while allowing the container to proceed since the directory was successfully created. However, silently ignoring the failure means permission hardening issues go undetected. Consider logging the chmod failure (without halting startup) to aid troubleshooting, especially given the complex UID/GID alignment requirements documented in the deployment guides.

Dockerfile (2)

29-29: Remove redundant hadolint ignore directive.

Based on learnings, DL3018 (Alpine package pinning) is already globally ignored in .hadolint.yaml. This inline directive is redundant and can be removed.

🔎 Proposed cleanup

-# hadolint ignore=DL3018
 RUN apk add --no-cache \

---

45-46: Consider pinning pip/setuptools/wheel versions for reproducible builds.

While the hadolint ignore allows unpinned upgrades, pinning these base tool versions would improve build reproducibility and prevent potential breakage from upstream changes.

🔎 Example with pinned versions

-# hadolint ignore=DL3013 
-RUN python -m pip install --no-cache-dir --upgrade pip setuptools wheel && \
+RUN python -m pip install --no-cache-dir --upgrade pip==24.0 setuptools==69.0.0 wheel==0.42.0 && \
     pip install --prefer-binary --no-cache-dir -r /tmp/requirements.txt && \

Note: Use current stable versions appropriate for your Python 3.12/Alpine 3.22 environment.

test/docker_tests/test_docker_compose_unit.py (1)

25-30: Suppress false-positive unused argument warnings.

The unused args and kwargs parameters are intentional to match the subprocess.run signature for mocking. Add a suppression comment to silence the static analysis warnings.

🔎 Proposed suppression

-    def fake_run(*args, **kwargs):
+    def fake_run(*args, **kwargs):  # noqa: ARG001
         try:
             return cps.pop(0)

test/docker_tests/test_puid_pgid.py (1)

101-114: Unnecessary env.pop call.

Line 103 removes SKIP_TESTS from env, but the env dict comes from the parametrized test data which doesn't contain SKIP_TESTS. The pop with default None is harmless but adds confusion.

🔎 Proposed simplification

 def test_invalid_puid_pgid_rejected(env: dict[str, str], expected: str) -> None:
-    env = {**env}
-    env.pop("SKIP_TESTS", None)
     result = _run_root_entrypoint(env=env)

install/production-filesystem/root-entrypoint.sh (1)

89-95: Condition at line 90 is always true.

Since PUID and PGID have defaults set at lines 23-24, the condition [ -n "${PUID:-}" ] || [ -n "${PGID:-}" ] is always true. The message will always print when running as non-root.

This may be intentional (always inform the user), but if the intent is to only warn when the user explicitly set PUID/PGID, you'd need to check before applying defaults.

test/docker_tests/test_mount_diagnostics_pytest.py (3)

67-76: Audit stream helper lacks timeout handling.

The Popen subprocess streams logs indefinitely with no mechanism to detect if the process hangs or becomes unresponsive. Consider adding a health check or documenting expected cleanup behavior.

Also note: This function signature differs from the one in test_docker_compose_scenarios.py (single container name vs list). If both are intentional, the naming similarity could cause confusion.

---

685-689: Silent exception swallowing during cleanup.

The bare except Exception: pass silently swallows all errors during audit process termination. While cleanup errors are often non-fatal, logging them would aid debugging per project guidelines.

🔎 Proposed fix

         if audit_proc:
             try:
                 audit_proc.terminate()
-            except Exception:
-                pass
+            except Exception as e:
+                print(f"[cleanup] audit_proc.terminate() failed: {e}")

---

799-804: Complex assertion condition could be simplified.

The multi-line or chain for checking capability-related messages is fragile and hard to read. Consider using a list-based approach for clarity.

🔎 Proposed simplification

-        assert (
-            "cap_chown" in logs.lower() or "cap chown" in logs.lower() or "cap_chown" in logs or "capabilities (chown" in logs.lower()
-        )
+        chown_indicators = ["cap_chown", "cap chown", "capabilities (chown"]
+        assert any(indicator in logs.lower() for indicator in chown_indicators), (
+            f"Expected CAP_CHOWN related message in logs. Got: {logs[:500]}"
+        )

test/docker_tests/test_docker_compose_scenarios.py (3)

44-63: Duplicate helper function across test files.

This capture_project_mandatory_required_audit_stream function is nearly identical to the one in test_mount_diagnostics_pytest.py but accepts a list of container names. Consider extracting to a shared test utilities module to reduce duplication.

Note: The function in test_mount_diagnostics_pytest.py (lines 67-76) accepts a single string while this accepts a list - both serve similar purposes but have different signatures.

---

652-656: Silent exception swallowing during process cleanup.

Same pattern as the other file - bare except Exception: pass silently swallows errors. Consider logging for consistency with the mandatory logging philosophy.

🔎 Proposed fix

     for proc in audit_streams:
         try:
             proc.terminate()
-        except Exception:
-            pass
+        except Exception as e:
+            print(f"[cleanup] audit stream terminate failed: {e}")

---

1027-1059: NET_RAW capability test mirrors NET_ADMIN test.

Both tests share nearly identical structure. If more capability-specific tests are added, consider parameterizing them.

These two tests could be combined using @pytest.mark.parametrize with the compose file and test name as parameters.

test/docker_tests/test_container_environment.py (2)

467-536: New test for root-to-user transition is well-structured.

The test properly validates the volume permission workflow:

1. Phase 1: Initialize volume as root
2. Phase 2: Restart as user 20211
3. Cleanup in finally block with detailed logging on failure

The cleanup logic at lines 500-533 has multiple nested try-except blocks that silently pass. While cleanup errors are often non-fatal, this pattern appears frequently and could benefit from a shared cleanup helper.

Consider extracting the cleanup pattern into a reusable helper:

def _safe_cleanup_container(container_name: str | None) -> None:
    """Best-effort container cleanup with logging."""
    if not container_name:
        return
    try:
        subprocess.run(["docker", "rm", "-f", container_name], 
                      check=False, stdout=subprocess.DEVNULL, 
                      stderr=subprocess.DEVNULL, timeout=15)
    except Exception as e:
        print(f"[cleanup] Failed to remove {container_name}: {e}")

---

684-689: Silent exception when setting container_name attribute.

The try-except silently ignores failures when attaching container_name to the result object. This is defensive but the comment "unexpectedly frozen" suggests uncertainty about when this could happen.

🔎 Proposed improvement with logging

     try:
         result.container_name = name  # type: ignore[attr-defined]
-    except Exception:
-        # Be resilient if CompletedProcess is unexpectedly frozen.
-        pass
+    except Exception as e:
+        print(f"[warning] Could not attach container_name to result: {e}")

docs/PUID_PGID_SECURITY.md (1)

1-23: Consider consolidating duplicated security guidance.

This file duplicates most of the content from docs/docker-troubleshooting/PUID_PGID_SECURITY.md (lines 1–23 are nearly identical). If the intent is to provide both a root-level quick reference and a detailed troubleshooting guide, consider making the root version significantly shorter (e.g., a one-paragraph summary with a link to the full guide), or consolidate into a single authoritative file with appropriate cross-references.

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Learnt from: CR
Repo: jokob-sk/NetAlertX PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-08T01:59:00.903Z
Learning: Devcontainer philosophy: brutal simplicity. One user, everything writable, completely idempotent. No permission checks, no conditional logic, no sudo needed.

test/docker_tests/test_mount_diagnostics_pytest.py (1)

67-77: Function signature inconsistency and missing timeout consideration.

This function shares the same name as capture_project_mandatory_required_audit_stream in test_docker_compose_scenarios.py but has a different signature (single container vs. list, different parameters). Consider:

1. Signature alignment: Rename this function (e.g., capture_single_container_audit_stream) or align the signatures for consistency.
2. Timeout consideration: While subprocess.Popen doesn't accept a timeout parameter, document that this audit stream is intentionally long-running and will be terminated in test cleanup (as seen in the finally block at lines 686-689).

Proposed solution: Rename and document

-def capture_project_mandatory_required_audit_stream(container_name: str) -> subprocess.Popen[str]:
-    """Stream container logs to stdout for auditing; required to stay enabled."""
+def capture_single_container_audit_stream(container_name: str) -> subprocess.Popen[str]:
+    """
+    Stream container logs to stdout for auditing; required to stay enabled.
+    
+    Note: This process runs indefinitely and must be terminated by the caller.
+    See test cleanup (finally blocks) for proper termination.
+    """

And update the call site at line 650:

-        audit_proc = capture_project_mandatory_required_audit_stream(container_name)
+        audit_proc = capture_single_container_audit_stream(container_name)

As per coding guidelines, subprocess calls should have explicit timeouts, but this is an exception since the audit stream must run continuously during the test.

install/production-filesystem/root-entrypoint.sh (2)

61-85: Capability checking logic is correct.

The function correctly extracts and validates Linux capability bits using POSIX-compliant methods. The warning for missing SETUID/SETGID alongside NET_* capabilities is a helpful diagnostic.

Line 78 exceeds 120 characters. Consider splitting the condition for readability:

🔎 Optional refactor for line length

-    if [ $((cap_dec & (1 << 10))) -ne 0 ] || [ $((cap_dec & (1 << 12))) -ne 0 ] || [ $((cap_dec & (1 << 13))) -ne 0 ]; then
+    # Check for CAP_NET_BIND_SERVICE(10), CAP_NET_ADMIN(12), CAP_NET_RAW(13)
+    if [ $((cap_dec & (1 << 10))) -ne 0 ] || \
+       [ $((cap_dec & (1 << 12))) -ne 0 ] || \
+       [ $((cap_dec & (1 << 13))) -ne 0 ]; then
         has_net_caps=1
     fi

---

102-119: Path priming logic is correct with non-fatal error handling.

The best-effort approach (using || true on all permission operations) correctly implements the design goal of not blocking startup on permission issues.

Line 104 is extremely long (>200 characters) and difficult to read/maintain. Consider using a multi-line array:

🔎 Optional refactor for readability

 _prime_paths() {
     runtime_root="${NETALERTX_RUNTIME_BASE:-/tmp}"
-    paths="/tmp ${NETALERTX_DATA:-/data} ${NETALERTX_CONFIG:-/data/config} ${NETALERTX_DB:-/data/db} ${NETALERTX_LOG:-${runtime_root}/log} ${NETALERTX_PLUGINS_LOG:-${runtime_root}/log/plugins} ${NETALERTX_API:-${runtime_root}/api} ${SYSTEM_SERVICES_RUN:-${runtime_root}/run} ${SYSTEM_SERVICES_RUN_TMP:-${runtime_root}/run/tmp} ${SYSTEM_SERVICES_RUN_LOG:-${runtime_root}/run/logs} ${SYSTEM_SERVICES_ACTIVE_CONFIG:-${runtime_root}/nginx/active-config} ${runtime_root}/nginx"
+    paths="
+        /tmp
+        ${NETALERTX_DATA:-/data}
+        ${NETALERTX_CONFIG:-/data/config}
+        ${NETALERTX_DB:-/data/db}
+        ${NETALERTX_LOG:-${runtime_root}/log}
+        ${NETALERTX_PLUGINS_LOG:-${runtime_root}/log/plugins}
+        ${NETALERTX_API:-${runtime_root}/api}
+        ${SYSTEM_SERVICES_RUN:-${runtime_root}/run}
+        ${SYSTEM_SERVICES_RUN_TMP:-${runtime_root}/run/tmp}
+        ${SYSTEM_SERVICES_RUN_LOG:-${runtime_root}/run/logs}
+        ${SYSTEM_SERVICES_ACTIVE_CONFIG:-${runtime_root}/nginx/active-config}
+        ${runtime_root}/nginx
+    "

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Learnt from: CR
Repo: jokob-sk/NetAlertX PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-08T01:59:00.903Z
Learning: Devcontainer philosophy: brutal simplicity. One user, everything writable, completely idempotent. No permission checks, no conditional logic, no sudo needed.

Learnt from: adamoutler
Repo: jokob-sk/NetAlertX PR: 1263
File: install/production-filesystem/entrypoint.sh:60-86
Timestamp: 2025-11-01T19:02:10.635Z
Learning: In the NetAlertX project (install/production-filesystem/entrypoint.sh), when fail-fast behavior is adopted for entrypoint checks in the future, be lenient during review because tests will be removed or changed to accommodate that behavior. The current continue-on-failure approach exists to support the existing test suite, but this is expected to change along with corresponding test adjustments.

Learnt from: adamoutler
Repo: jokob-sk/NetAlertX PR: 1235
File: install/production-filesystem/services/scripts/check-first-run-config.sh:0-0
Timestamp: 2025-10-26T15:39:36.707Z
Learning: In NetAlertX startup scripts, critical initialization failures (e.g., unable to create config directory or copy default config files) should exit with non-zero status to fail fast and provide clear error messages, rather than continuing in a broken state.

Learnt from: CR
Repo: jokob-sk/NetAlertX PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-08T01:59:00.903Z
Learning: Applies to **/*.py : Use environment variables (`NETALERTX_DB`, `NETALERTX_LOG`, etc.) everywhere instead of hardcoding paths like `/data/db` or relative paths.

Learnt from: adamoutler
Repo: jokob-sk/NetAlertX PR: 1235
File: install/production-filesystem/services/scripts/check-ramdisk.sh:0-0
Timestamp: 2025-10-26T16:45:41.247Z
Learning: In NetAlertX check scripts (install/production-filesystem/services/scripts/check-*.sh), not all checks should exit with non-zero status. Some checks, like check-ramdisk.sh, are warning-only and exit 0 even when issues are detected, allowing the application to start despite suboptimal configuration.

Learnt from: adamoutler
Repo: jokob-sk/NetAlertX PR: 1184
File: .devcontainer/scripts/setup.sh:103-116
Timestamp: 2025-09-20T14:09:29.159Z
Learning: In NetAlertX devcontainer setup, the netalertx user has write permissions to /var/log/nginx/ directory as it's explicitly chowned to netalertx:www-data in the Dockerfile, so setup.sh can write to nginx log files without sudo.

Learnt from: adamoutler
Repo: jokob-sk/NetAlertX PR: 1184
File: .devcontainer/scripts/setup.sh:90-96
Timestamp: 2025-09-20T14:08:48.256Z
Learning: In the NetAlertX devcontainer setup, the setup.sh script intentionally removes user_notifications.json from the API directory during development environment initialization to prevent notification clutter that accumulates during container launches and development work.

Learnt from: adamoutler
Repo: jokob-sk/NetAlertX PR: 1184
File: .devcontainer/Dockerfile:18-19
Timestamp: 2025-09-20T03:01:19.912Z
Learning: In the NetAlertX repository, .devcontainer/Dockerfile is auto-generated and should not be reviewed directly. Review comments about dependencies and build steps should be directed at the root Dockerfile where the actual source commands are located.

Learnt from: adamoutler
Repo: jokob-sk/NetAlertX PR: 1184
File: .devcontainer/devcontainer.json:5-8
Timestamp: 2025-09-20T02:56:24.501Z
Learning: In the NetAlertX devcontainer setup, the final .devcontainer/Dockerfile is generated by combining the root Dockerfile with .devcontainer/resources/devcontainer-Dockerfile using the generate-dockerfile.sh script. The devcontainer.json should reference the generated file, not the root Dockerfile.

Learnt from: CR
Repo: jokob-sk/NetAlertX PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-08T01:59:00.903Z
Learning: Applies to .devcontainer/**/* : Never `chmod` or `chown` during operations in devcontainer. Everything is already writable. If you need permissions, the devcontainer setup is broken - fix `.devcontainer/scripts/setup.sh` or `.devcontainer/resources/devcontainer-Dockerfile` instead.

Learnt from: CR
Repo: jokob-sk/NetAlertX PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-08T01:59:00.903Z
Learning: Devcontainer philosophy: brutal simplicity. One user, everything writable, completely idempotent. No permission checks, no conditional logic, no sudo needed.

Learnt from: adamoutler
Repo: jokob-sk/NetAlertX PR: 1235
File: .devcontainer/scripts/setup.sh:146-148
Timestamp: 2025-10-26T17:09:18.621Z
Learning: In `.devcontainer/scripts/setup.sh` and other devcontainer setup scripts for NetAlertX, chmod 666 on /var/run/docker.sock is acceptable because devcontainer environments are single-user development contexts where convenience can take priority over strict permission hardening.

Learnt from: adamoutler
Repo: jokob-sk/NetAlertX PR: 1184
File: .devcontainer/Dockerfile:11-16
Timestamp: 2025-09-20T14:13:33.635Z
Learning: In the NetAlertX devcontainer setup, the `python -m venv /opt/venv` command works successfully on Alpine 3.22 despite the typical Alpine behavior of not providing a /usr/bin/python symlink by default. The build completes successfully and pytest runs without issues.

Learnt from: adamoutler
Repo: jokob-sk/NetAlertX PR: 1230
File: .devcontainer/resources/devcontainer-overlay/services/config/nginx/netalertx.conf.template:1-2
Timestamp: 2025-10-19T01:40:57.095Z
Learning: In the NetAlertX repository, .devcontainer/resources/devcontainer-overlay/services/config/nginx/netalertx.conf.template is an auto-generated file that is intentionally committed to source control. It cannot be regenerated automatically outside the devcontainer environment and is required for the devcontainer to start, creating a bootstrap dependency.

Learnt from: adamoutler
Repo: jokob-sk/NetAlertX PR: 1214
File: install/ubuntu24/uninstall.sh:129-141
Timestamp: 2025-10-10T22:16:02.770Z
Learning: NetAlertX uninstall procedures should only remove files from the repository (specifically /app files) and should not touch system packages like PHP, nginx, avahi, or other shared system components to avoid damaging user systems.

Learnt from: adamoutler
Repo: jokob-sk/NetAlertX PR: 1184
File: .devcontainer/Dockerfile:11-16
Timestamp: 2025-09-20T14:13:33.635Z
Learning: In the NetAlertX repository with Alpine 3.22 base image, the `python -m venv` command works correctly in the devcontainer setup, likely due to symlink creation in the root Dockerfile that makes `python` available as an alias to `python3`.

Learnt from: adamoutler
Repo: jokob-sk/NetAlertX PR: 1230
File: front/plugins/dhcp_servers/script.py:44-44
Timestamp: 2025-10-19T15:29:46.423Z
Learning: In the NetAlertX dhcp_servers plugin (front/plugins/dhcp_servers/script.py), the nmap command uses both 'sudo' and '--privileged' flag to maintain cross-platform compatibility. While the hardened Docker image stubs sudo and uses capabilities, hardware installations (Debian 12, Ubuntu 24) and the Debian Dockerfile require sudo for raw socket access. This approach ensures the plugin works across all deployment targets.

Learnt from: adamoutler
Repo: jokob-sk/NetAlertX PR: 1304
File: .hadolint.yaml:1-2
Timestamp: 2025-11-24T00:56:58.733Z
Learning: In the NetAlertX repository, the .hadolint.yaml config file is intentionally configured to only globally ignore DL3018 (Alpine package pinning). Rules DL3006 (explicit image tagging) and SC2114 (deleting system directories) are handled via inline `# hadolint ignore` directives in specific Dockerfiles where needed, rather than being globally ignored, to ensure new Dockerfiles are still checked for these rules.

Learnt from: adamoutler
Repo: jokob-sk/NetAlertX PR: 1184
File: .devcontainer/scripts/stream-logs.sh:5-6
Timestamp: 2025-09-20T14:08:44.292Z
Learning: The .devcontainer/scripts/stream-logs.sh script in NetAlertX is designed as a diagnostic tool for troubleshooting devcontainer startup issues. When log files don't exist, this indicates that the executable/services didn't start properly, which is valuable diagnostic information. Pre-creating missing files would mask this diagnostic behavior.

Learnt from: adamoutler
Repo: jokob-sk/NetAlertX PR: 1184
File: .devcontainer/Dockerfile:82-92
Timestamp: 2025-09-20T14:08:44.152Z
Learning: In devcontainer builds, source repository files are not available during the Docker build phase. The source code gets mounted into the container after it's built and started, so COPY commands referencing source files will fail. Configuration files need to be handled at runtime (e.g., in setup scripts) rather than during the build stage.

Dockerfile (1)

191-191: The entrypoint.sh script uses only POSIX sh-compatible syntax and does not require bash.

The script contains no bash-specific features (no arrays, bash-specific builtins, or process substitution). It uses only standard POSIX sh syntax including variable expansion, conditionals, and built-in commands. While bash will run the script without issues since it's installed, the change from /bin/sh to /bin/bash is unnecessary and adds overhead in a minimal container context. Consider reverting to /bin/sh for consistency with Alpine's lightweight design philosophy.

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Learnt from: adamoutler
Repo: jokob-sk/NetAlertX PR: 1184
File: .devcontainer/Dockerfile:11-16
Timestamp: 2025-09-20T14:13:33.635Z
Learning: In the NetAlertX devcontainer setup, the `python -m venv /opt/venv` command works successfully on Alpine 3.22 despite the typical Alpine behavior of not providing a /usr/bin/python symlink by default. The build completes successfully and pytest runs without issues.

Learnt from: adamoutler
Repo: jokob-sk/NetAlertX PR: 1184
File: .devcontainer/scripts/setup.sh:103-116
Timestamp: 2025-09-20T14:09:29.159Z
Learning: In NetAlertX devcontainer setup, the netalertx user has write permissions to /var/log/nginx/ directory as it's explicitly chowned to netalertx:www-data in the Dockerfile, so setup.sh can write to nginx log files without sudo.

Learnt from: adamoutler
Repo: jokob-sk/NetAlertX PR: 1214
File: install/ubuntu24/uninstall.sh:129-141
Timestamp: 2025-10-10T22:16:02.770Z
Learning: NetAlertX uninstall procedures should only remove files from the repository (specifically /app files) and should not touch system packages like PHP, nginx, avahi, or other shared system components to avoid damaging user systems.

Learnt from: adamoutler
Repo: jokob-sk/NetAlertX PR: 1184
File: .devcontainer/Dockerfile:11-16
Timestamp: 2025-09-20T14:13:33.635Z
Learning: In the NetAlertX repository with Alpine 3.22 base image, the `python -m venv` command works correctly in the devcontainer setup, likely due to symlink creation in the root Dockerfile that makes `python` available as an alias to `python3`.

Learnt from: adamoutler
Repo: jokob-sk/NetAlertX PR: 1230
File: front/plugins/dhcp_servers/script.py:44-44
Timestamp: 2025-10-19T15:29:46.423Z
Learning: In the NetAlertX dhcp_servers plugin (front/plugins/dhcp_servers/script.py), the nmap command uses both 'sudo' and '--privileged' flag to maintain cross-platform compatibility. While the hardened Docker image stubs sudo and uses capabilities, hardware installations (Debian 12, Ubuntu 24) and the Debian Dockerfile require sudo for raw socket access. This approach ensures the plugin works across all deployment targets.

Learnt from: adamoutler
Repo: jokob-sk/NetAlertX PR: 1235
File: .devcontainer/scripts/setup.sh:146-148
Timestamp: 2025-10-26T17:09:18.621Z
Learning: In `.devcontainer/scripts/setup.sh` and other devcontainer setup scripts for NetAlertX, chmod 666 on /var/run/docker.sock is acceptable because devcontainer environments are single-user development contexts where convenience can take priority over strict permission hardening.

Learnt from: adamoutler
Repo: jokob-sk/NetAlertX PR: 1304
File: .hadolint.yaml:1-2
Timestamp: 2025-11-24T00:56:58.733Z
Learning: In the NetAlertX repository, the .hadolint.yaml config file is intentionally configured to only globally ignore DL3018 (Alpine package pinning). Rules DL3006 (explicit image tagging) and SC2114 (deleting system directories) are handled via inline `# hadolint ignore` directives in specific Dockerfiles where needed, rather than being globally ignored, to ensure new Dockerfiles are still checked for these rules.

Learnt from: CR
Repo: jokob-sk/NetAlertX PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-08T01:59:00.903Z
Learning: Applies to .devcontainer/**/* : Never `chmod` or `chown` during operations in devcontainer. Everything is already writable. If you need permissions, the devcontainer setup is broken - fix `.devcontainer/scripts/setup.sh` or `.devcontainer/resources/devcontainer-Dockerfile` instead.