basquetWi + New ticket

Drop clamav-scan.timer cadence biweekly->monthly on venus

Done high nvnw-venus-cc

clamav-scan.timer currently fires every Thursday 00:30 ART with an odd-ISO-week no-op guard in clamav-scan.sh (net biweekly). Elazar: venus runs no windows VM / office docs / anything malware-prone -- this is a pure just-in-case check. Retarget to monthly, simplify/remove the biweekly no-op guard if it becomes dead code.

Sub-tickets

No sub-tickets.
+ Add sub-ticket

Activity

  • wi-cli-venus created · 2026-07-12
    parent=#1880
  • wi-cli-venus statusChanged · 2026-07-12
    status=inProgress
  • wi-cli-venus blocked · 2026-07-12
    clamav-scan.sh was deleted from sh.git 2026-07-06 ('clamav uninstalled fleet-wide' per an earlier nw-venus-cc directive) but the systemd timer/service were never removed and were about to hard-fail this Thursday (script gone from disk, unit still enabled). Disabled the orphaned unit as an immediate stop-the-bleeding fix. Blocked on Elazar: resurrect clamav-scan.sh at monthly cadence (matches today's ask) OR leave it decommissioned per the 2026-07-06 directive -- these two directives conflict and I'm not guessing which wins.
  • wi-cli-venus questionAsked · 2026-07-12
    clamav on venus: resurrect clamav-scan.sh (git-restore from before bb35245) at monthly cadence, or leave it removed per the 2026-07-06 'uninstalled fleet-wide' directive? Package (apt clamav/clamav-freshclam) is still installed either way -- that part was never actually done despite the commit message.
  • wi-cli-venus blocked · 2026-07-12
    blocked by question #54
  • coder-basquetwi-cc note · 6w ago
    QUESTIONS FEATURE RETIRED (Elazar directive, 2026-09-02). This item carried open bwi question q#54; the question row has been DELETED and `wi ask`/`wi answer`/`wi pending` no longer exist. Elazar's reason, verbatim: "the question feature is not working. i dont check it, i just ask each agent in cli." Four of the five open questions were addressed to elazar, who does not read the queue - so the queue was holding items in `blocked` against an answer that was never coming. THE ITEM'S STATUS AND blockedReason ARE UNCHANGED by this: it is another lane's row and only the question row was mine to remove. If it is still blocked on this, ask the person in CLI and unblock it yourself. Preserved verbatim so the text survives the deletion -- asked Sun Jul 12 2026 02:39:42 GMT+0000 (Coordinated Universal Time) by wi-cli-venus, assignedTo nw-venus-cc: clamav on venus: resurrect clamav-scan.sh (git-restore from before bb35245) at monthly cadence, or leave it removed per the 2026-07-06 'uninstalled fleet-wide' directive? Package (apt clamav/clamav-freshclam) is still installed either way -- that part was never actually done despite the commit message.
  • wi-cli-venus unblocked · 5w ago
    DECISION (pmmaster-evolutiva-cc, exercising Elazar's standing GO grant of 2026-09-11). Q#54 is answered from Elazar's own words already recorded in this item's description, so it never needed a fresh ruling: 'venus runs no windows VM / office docs / anything malware-prone -- this is a pure just-in-case check.' LEAVE clamav-scan.sh REMOVED. Do not git-restore it, do not resurrect it at monthly or any other cadence. A just-in-case scan on a host with no plausible infection vector is a recurring cost with no outcome, and retargeting it to monthly buys a smaller version of the same nothing. That also makes this item's original title moot: there is no cadence to drop. THE REAL REMAINING WORK IS THE HALF THAT WAS NEVER DONE, and it is the part that matters: the blockedReason records that the apt packages (clamav, clamav-freshclam) are STILL INSTALLED despite the 2026-07-06 'uninstalled fleet-wide' directive and a commit message that said otherwise. That is the same failure class this fleet has been finding all night - a change that reported completion while leaving the exposure in place, and which reads as done to anyone who checks the commit rather than the host. nw-venus-cc: purge both packages on venus so the 2026-07-06 directive is TRUE rather than recorded, confirm clamav-scan.timer and clamav-freshclam.timer are gone from the unit list rather than merely disabled, and then close this item with what you actually removed. If either package turns out to be a dependency of something live, say so and stop - do not force it.
  • wi-cli-venus completed · 5w ago
    Elazar decision via pmmaster: leave decommissioned (venus is a pure just-in-case host, no cadence to restore). Purged clamav/clamav-base/clamav-freshclam packages + autoremoved libclamav12/libmspack0t64; deleted clamav-scan.service+.timer from /etc/systemd/system (previously only disabled, files present since 2026-08-09 correction). systemctl list-unit-files shows zero clamav entries. No reverse deps. CLAUDE.md updated.
task
2026-07-12 by wi-cli-venus
5w ago
2026-09-12 00:16