I know this process is described in https://www.clamav.net/documents/private-local-mirrors but I had some additional questions. First, assuming I am choosing option 2 (serve CVD files from a local web server) when it says, ?let freshclam download the *.cvd files from http://database.clamav.net to the webserver?s DocumentRoot.? how, exactly, is one supposed to do that? The simplest choice I can see is to change DatabaseDirectory in freshclam.conf to /var/www/html but my concern with that the current /var/lib/clamav DatabaseDirectory on my existing servers running clam contain the uncompressed cld files, not the cvd files. So does that mean freshclam decompresses the files in the DatabaseDirectory location? Since I?ll only be serving as a mirror to clients in the same server cluster, I?m not as concerned about bandwidth usage as I am with this process actually working if I?m offering CLD files rather than CVD files as the instructions say. Or is there a part to the private local mirror setup I?m missing, like setting up an entirely different mechanism for pulling CVD files using a bash script with wget commands, or something like that?
Secondarily, I?m wondering if there are any gotchas I should be watching for on the web server side, itself. The 2 most obvious things that come to mind are DAC rights and SELinux concerns. For the DAC rights, the clamupdate user created with my clamav install doesn?t have rights to write to my /var/www/html directory. My instinct is to fix this with a group change on that directory to clamupdate allowing root to retain ownership as before, but letting freshclam write to the directory, as well. Is it that simple or is there something additional / entirely different I should be doing? In regards to SELinux, will files pulled down by freshclam just adopt the type label of the destination directory or does freshclam do some fanciness like download into a working directory with completely different labelling and then move the files at the end to DatabaseDirectory where they won?t have a label that allows Apache to serve them without having to do a restorecon, first? And then, of course, there?s the matter of what the labelling on those files should be. I assume they need to be of type antivirus_db_t to be used by clam, but they also need to be httpd_sys_content_t to be served by Apache. This makes me question my original plan to change DatabaseDirectory to /var/www/html in freshclam.conf, but I?m not sure what instead.
Obviously I can just try things and mess around until they work, but I thought I?d see what wisdom the list may offer. Any advice, suggestions or insights would be appreciated.
Thanks,
Scott
Secondarily, I?m wondering if there are any gotchas I should be watching for on the web server side, itself. The 2 most obvious things that come to mind are DAC rights and SELinux concerns. For the DAC rights, the clamupdate user created with my clamav install doesn?t have rights to write to my /var/www/html directory. My instinct is to fix this with a group change on that directory to clamupdate allowing root to retain ownership as before, but letting freshclam write to the directory, as well. Is it that simple or is there something additional / entirely different I should be doing? In regards to SELinux, will files pulled down by freshclam just adopt the type label of the destination directory or does freshclam do some fanciness like download into a working directory with completely different labelling and then move the files at the end to DatabaseDirectory where they won?t have a label that allows Apache to serve them without having to do a restorecon, first? And then, of course, there?s the matter of what the labelling on those files should be. I assume they need to be of type antivirus_db_t to be used by clam, but they also need to be httpd_sys_content_t to be served by Apache. This makes me question my original plan to change DatabaseDirectory to /var/www/html in freshclam.conf, but I?m not sure what instead.
Obviously I can just try things and mess around until they work, but I thought I?d see what wisdom the list may offer. Any advice, suggestions or insights would be appreciated.
Thanks,
Scott