Maybe I didn't state my point clearly enough. Apparently, my siting http as something I wanted to avoid made you think that it was http in particular that I object to. Not so. It is networking in general I'm trying to avoid. Did you notice that I said the target machine is not on any kind of network, not even a local LAN? It has no wireless. There's no ethernet cable plugged into it.
Okay, so the local private mirror solution does not require the final target to use http. So I could do without a web server. But it does require the final target to use networking, yes? DNS? So I *could* make it work, but I'd have to run a domain name server on the target machine, and it would need its loopback network interface running. All this just so the final target, which is the client, can ask the server, which is also the final target machine, one little question that has a short text string for an answer. That seems to me like an awfully "big hammer", considering that otherwise, on a stand-alone machine, networking is entirely unnecessary. All I'm saying is that, for the admittedly unusual but definitely simpler situation of an entirely stand-alone, completely non-networked machine, it would be nice if there were a solution that was correspondingly simpler. One that used the file system only, not networking. On Wed, Jul 22, 2015 at 7:00 PM, Al Varnell <alvarn...@mac.com> wrote: > Please read the solutions a bit more closely. The HTTP portion of some of > those solutions is to bring the database to the local mirror. Since you > have already said you plan to burn optical disks and manually install them > on the private mirror, that should not be an issue. From there you can > just tell freshclam where to find the mirror on your network with an IP > address and path to the database. > > Be aware that even freshclam will fall back to an http solution should a > direct download fail, but that should not be a problem with a stable > network. > > -Al- > > On Jul 22, 2015, at 12:13 PM, Phil Dumont <p...@solidstatescientific.com> > wrote: > > I *did* read the private local mirrors stuff. It offers 3 alternative > > solutions, all of which require http. If you'll read my original post > more > > carefully, you'll see that that is what I'm trying to avoid. > > > > On Wed, Jul 22, 2015 at 2:22 PM, Al Varnell <alvarn...@mac.com> wrote: > >> See Private Local Mirrors: < > http://www.clamav.net/doc/mirrors-private.html > >> > >> -Al- > >> > >> On Jul 22, 2015, at 9:04 AM, Phil Dumont wrote: > >>> I'm considering using clamav on a machine that is not (can not be) on > the > >>> network (any network, not even a local one). > >>> > >>> I have a few ideas for how to get virus definition updates onto the > >>> machine, but none of them is quite perfect. > >>> > >>> All of them start with getting on an online computer and pulling the > .cvd > >>> files (main, daily, bytecode) off the net and onto on optical disk, > then > >>> sticking that disk into the offline machine. > >>> > >>> Then what? > >>> > >>> I'd like to use freshclam, just because that's the "official" way to > do it. > >>> > >>> I get that I can add some DatabaseCustomURL directives to my > >>> freshclam.conf, with file URLs that just point directly to wherever the > >>> optical disk will be mounted. That works. > >>> > >>> The part I haven't figured out yet is if there is any way to get > freshclam > >>> *not* to go out on the web to verify the databases. > >>> > >>> As far as I can tell, there is no way to tell it to just skip that > step, > >>> which is what I would prefer. > >>> > >>> Alternatively, is there any way to make it do it locally? > >>> > >>> There's PrivateMirror, which would be fine if it's value could be a > file > >>> URL, but it seems to want a host name to build an http URL out of. > Which > >>> means, for my offline computer, I have to have at least loopback > networking > >>> runnng, and an HTTP server, which I'd rather not do. > >>> > >>> I could just let freshclam try and fail to verify the databases. But > that > >>> makes the command take longer than it should while waiting for the http > >>> attempts to time out, and clutters the logs with unsightly error > messages. > >>> > >>> The only other alternative I can think of is to use cp or rsync or some > >>> such to copy the .cvd files from the optical disk to /var/lib/clamav > "by > >>> hand". This avoids unsightly error messages in the log, but that’s > because > >>> it doesn't put *anything* in the logs. Which is unfortunate, because > I'd > >>> like to have a record of when the updates were done. I suppose I could > >>> right my own script that copies the databases into place *and* logs the > >>> fact. > >>> > >>> Any input? > _______________________________________________ > Help us build a comprehensive ClamAV guide: > https://github.com/vrtadmin/clamav-faq > > http://www.clamav.net/contact.html#ml _______________________________________________ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
