Remove Virusscan option

[Sebastian-Roth]

Details in the forum topic: https://forums.fogproject.org/topic/13518/fog-1-5-6-arch-linux-antivirus-scan

Cross linking this to the fos issue #28 as there are components in both repos: FOGProject/fos#28

[Sebastian-Roth]

Marked as feature (removal), will have to wait.

[Sebastian-Roth]

Would need schema update as well. We'll delay this until the merge with working-1.6 is done.

[mastacontrola]

Done across both repositories, as the issue anticipated.

Server	#1608 → working-1.6 (2d9ca3766)
Boot image	FOGProject/fos#170 → master (b44ee2c82), closing FOGProject/fos#28

Server side (#1608)

Schema step 406 removes task types 9, 21 and 22, then drops the virus table. The ordering is the part that mattered: tasks.taskTypeID and scheduledTasks.stTaskTypeID both reference taskTypes.ttID ON DELETE RESTRICT, and errno 1451 is not in Schema::runSteps()'s skippable list. Deleting the parent first aborts the update at ?node=schema for every server that has ever queued a scan — while passing cleanly on an empty test database, which is exactly the shape of failure that reaches users and no static check can see.

So it was proved against a clone of a live 1.6 database rather than reasoned about: the naive order refuses with 1451, step 406 runs clean, the taskLog row survives, and a second run is a no-op. The step is also written to clear the children generically, and tests/virus-scan-is-removed.test.php fails the build if a future enabled RESTRICT child of taskTypes is added without a matching delete.

Also removed: the clamav= kernel argument and the [21, 22] special-case in BootMenuBase, the virus.vHostMAC relationship from the constraint map, and the table from the schema manifest — declared retired, with a reason, rather than silently dropped. The historical steps that created the table and seeded the rows stay exactly as they are; commons/schema.php is an append-only replay log and rewriting an old step changes what a 1.5 database replays into.

Why this was safe to remove rather than fix

Worth recording, because the feature looks alive on 1.5 and I nearly stopped on that basis. It cannot run on either line, three independently:

• No ClamAV in the boot image. BR2_PACKAGE_CLAMAV is not set in both fsx64.config and fsarm64.config.
• No ClamAV on the server either. fog.av NFS-mounts the binaries from <server>:/opt/fog/clamav, the path the clamav= argument carried. Neither installer has ever created or exported that directory — no reference to clamav in bin/ or lib/ on working-1.6 or dev-branch, and it is absent from a live server's filesystem and /etc/exports. The mount fails and the script dies at handleError "Cannot find clamav binaries to run task." before reaching a partition.
• Nowhere to report to. 1.6 never carried service/av.php across from 1.5. 1.5 has it, but its guard is if (trim($_REQUEST['mode']) != array('q', 's')) — a string compared to an array, where PHP ranks any array above any non-array. That is true for every input, so the endpoint has thrown "Invalid operational mode" and saved nothing since the line was written in 2014. Verified on 7.4.33 and 8.3.33.

Note for the 1.5 line

dev-branch still offers all three task types and still emits mode=clamav, so a 1.5 Virus Scan now fails as Unknown mode :: clamav rather than Cannot find clamav binaries. Both are handleError paths reached before any scanning, so nothing that worked has been lost — but 1.5 still has the Virus model, VirusManager, the virus history report and the icon, and removing those is a separate change against dev-branch that this issue does not cover.

Closing by hand: this repository's default branch is stable, so a closing keyword in a pull request against working-1.6 never fires.