Shieldlist/shieldlist-agent
Watch
1
0
Fork
You've already forked shieldlist-agent
 0
Code Issues Pull requests Projects Releases 4 Packages Wiki Activity Actions
4 releases 4 tags
  • v0.0.2 5ac56e5d2d

    v0.0.2 Pre-release

    Robin released this 2026-08-15 00:30:20 +02:00 | 151 commits to main since this release

    Three fixes from putting v0.0.1 on a real, busy production machine — a
    hosting node with a database, twenty PHP pools and twenty-three sites.
    Every one of them was invisible on a quiet test box.

    The agent's memory ceiling no longer follows the machine

    The agent used to subtract a reserve from the machine's currently
    available     memory, so that it would "give room back" as the protected
    service grew. On a machine that genuinely uses its memory it did the
    opposite of its intent: a nightly job pushed available memory under the
    reserve, and the agent's budget collapsed from 929 446 buffered events
    to 16 384 — while the process was holding 16 MB. It shed a capacity it
    had never taken, because of what something else was doing at midnight.

    limits.memory is now a fixed ceiling and the whole of the policy.
    The agent reads MemTotal — enough to resolve 25% — and nothing else.
    It does not watch free memory and does not shrink when something else
    grows.

    A program whose behaviour depends on the rest of the box is one whose
    behaviour cannot be reproduced, and one that competes with every other
    program for the same slack. Tell this one what it may have; dividing the
    rest is the administrator's job, and MemoryMax in the unit is the tool
    for it.

    Exemptions were being silently discarded

    loadList decoded straight into the destination slice, and yaml.v3
    replaces a slice rather than appending to it. So the second
    exemption file read discarded the first: the moment shield exempt
    created exemptions-cli.yaml, every exemption written by hand stopped
    existing — an operator's own infrastructure included — and nothing said
    so. The count in shieldlist-agent -t was the only trace, and only if
    you knew what it should have been.

    If you have ever run shield exempt, check the count:

    shieldlist-agent -t

    exemptions.d/

    The useful exemption lists are generated: the ranges Google and Bing
    publish run to a couple of thousand entries and are refreshed from a
    source. Pasted into exemptions.yaml they bury the dozen a person
    maintains, and the next refresh has to preserve them.

    /etc/shieldlist/
  exemptions.yaml         yours
  exemptions.d/*.yaml     one file per generated source
  exemptions-cli.yaml     what `shield exempt` wrote

    All of them load, and each entry remembers which file it came from.

    The agent writes its own log

    Under systemd the log goes to the journal, which is right — but
    /var/log is the first place anyone looks after starting a security
    daemon, and finding nothing there reads as "it did not start".

    log_file: /var/log/shieldlist/agent.log

    Set in the shipped configuration, with the same lines as journalctl -u shieldlist-agent. The lines written before the configuration was read
    are replayed into it, so it holds the whole run. No logrotate snippet
    ships with it: the file is identified by (device, inode) like every
    other file the agent follows, so a rename is noticed and the file
    reopened. The unit gains LogsDirectory=shieldlist, without which
    ProtectSystem=strict leaves /var/log unwritable.

    Upgrading

    install.sh again — it replaces the binaries and touches no
    configuration. Which means an existing install needs log_file added by
    hand if you want the file.

    Still pre-1.0 and still unsigned: the checksums prove the download was
    not corrupted and nothing more.

    Downloads