[clamav-users] Install ClamAV on RHEL v7
Hi everybody! Could you tell about what the difference is between clamd@scan.service and clamd@.service? When do these services use? I installed ClamAV on RHEL and tried to start these services. The service clamd normally started but another service could start. What is wrong I did? # systemctl status clamd.service ● clamd.service - clamd scanner daemon Loaded: loaded (/usr/lib/systemd/system/clamd.service; enabled; vendor preset: disabled) Active: active (running) since Thu 2016-11-24 14:33:38 +08; 37min ago Main PID: 1617 (clamd) CGroup: /system.slice/clamd.service └─1617 /usr/sbin/clamd -c /etc/clamd.d/clamd.conf --foreground=yes Nov 24 14:33:52 usk.***.ru clamd[1617]: OLE2 support enabled. Nov 24 14:33:52 usk.***.ru clamd[1617]: PDF support enabled. Nov 24 14:33:52 usk.***.ru clamd[1617]: SWF support enabled. Nov 24 14:33:52 usk.***.ru clamd[1617]: HTML support enabled. Nov 24 14:33:52 usk.***.ru clamd[1617]: XMLDOCS support enabled. Nov 24 14:33:52 usk.***.ru clamd[1617]: HWP3 support enabled. Nov 24 14:33:52 usk.***.ru clamd[1617]: Self checking every 600 seconds. Nov 24 14:43:52 usk.***.ru clamd[1617]: SelfCheck: Database status OK. Nov 24 14:53:52 usk.***.ru clamd[1617]: SelfCheck: Database status OK. Nov 24 15:03:52 usk.***.ru clamd[1617]: SelfCheck: Database status OK. # systemctl start clamd@scan.service Failed to start clamd@scan.service: Unit is not loaded properly: Invalid argument. See system logs and 'systemctl status clamd@scan.service' for details. # journalctl -b -u clamd@scan.service -- Logs begin at Tue 2016-11-15 10:52:51 +08, end at Thu 2016-11-24 15:21:13 +08. -- Nov 24 14:58:07 usk.***.ru systemd[1]: clamd@scan.service lacks both ExecStart= and ExecStop= setting. Refusing. Nov 24 14:58:08 usk.***.ru systemd[1]: Cannot add dependency job for unit clamd@scan.service, ignoring: Unit is not loaded properly: Invalid argument. Nov 24 15:18:21 usk.***.ru systemd[1]: clamd@scan.service lacks both ExecStart= and ExecStop= setting. Refusing. Best regards, Misha. ___ clamav-users mailing list clamav-users@lists.clamav.net http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
Re: [clamav-users] TTL of DNS recode
I realise English is not your main language and this is probably very difficult for you to explain in what is to you a foreign language, but I don't think we are able to figure out just what is not working ... Tsutomu Oyamada wrote: > In the present situation fail. What is failing ? Does your local mirror update ? If not, post logs from freshclam showing the failures to update. Also post your freshclam config. If your local mirror does update, then we assume your local clients are failing to update from your mirror. If that is the case, post the freshclam logs from a failing client, and it's config. ___ clamav-users mailing list clamav-users@lists.clamav.net http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
Re: [clamav-users] TTL of DNS recode
In the present situation fail. However, it did not fail one month ago. I do not have log had been successful. Want to know why should I fail to have succeeded in that. On Thu, 24 Nov 2016 01:19:20 -0800 Al Varnell wrote: > What is no longer working fine now? > > Do you have some example freshclam.logs that show issues? > > What ClamAV.net mirrors are you using? ___ clamav-users mailing list clamav-users@lists.clamav.net http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
Re: [clamav-users] TTL of DNS recode
What is no longer working fine now? Do you have some example freshclam.logs that show issues? What ClamAV.net mirrors are you using? $ host database.clamav.net -Al- On Thu, Nov 24, 2016 at 01:11 AM, Tsutomu Oyamada wrote: > > Hi, Al. > > Thank you for your reply. > > I tested in the following environments. > > ClamAV .net >| (Mirroring once every day) > My local update server >|(after 24 hours at mirroring) > freshclam > > Worked fine until a month ago in this environment. > > T.O. > > On Wed, 23 Nov 2016 19:30:56 -0800 > Al Varnell wrote: > >> I'm having difficulty following some of your questions and have no answers >> yet, but what exactly is your mirror environment (IPs)? >> >> Sent from Janet's iPad >> >> -Al- >> >> On Nov 23, 2016, at 7:10 PM, Tsutomu Oyamada wrote: >>> Hi, All. >>> >>> We know CVD version information is published in DNS TXT record, this >>> record's TTL values, 1800 seconds is currently is. This value is the >>> same from the previous? >>> >>> Also in freshclam download old versions of CVD(one day ago) in local >>> mirror environment, we will succeed. >>> >>> I thought I was bound to fail. >>> >>> Why not? >>> >>> T.O >> ___ >> clamav-users mailing list >> clamav-users@lists.clamav.net >> http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users >> >> >> Help us build a comprehensive ClamAV guide: >> https://github.com/vrtadmin/clamav-faq >> >> http://www.clamav.net/contact.html#ml >> > > > ___ > clamav-users mailing list > clamav-users@lists.clamav.net > http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users > > > Help us build a comprehensive ClamAV guide: > https://github.com/vrtadmin/clamav-faq > > http://www.clamav.net/contact.html#ml -Al- -- Al Varnell Mountain View, CA smime.p7s Description: S/MIME cryptographic signature ___ clamav-users mailing list clamav-users@lists.clamav.net http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
Re: [clamav-users] TTL of DNS recode
Read your freshclam.log file and see if there is any useful information in their to help solve your problem. dp On 11/24/16 1:11 AM, Tsutomu Oyamada wrote: Hi, Al. Thank you for your reply. I tested in the following environments. ClamAV .net | (Mirroring once every day) My local update server |(after 24 hours at mirroring) freshclam Worked fine until a month ago in this environment. T.O. ___ clamav-users mailing list clamav-users@lists.clamav.net http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
Re: [clamav-users] TTL of DNS recode
Hi, Al. Thank you for your reply. I tested in the following environments. ClamAV .net | (Mirroring once every day) My local update server |(after 24 hours at mirroring) freshclam Worked fine until a month ago in this environment. T.O. On Wed, 23 Nov 2016 19:30:56 -0800 Al Varnell wrote: > I'm having difficulty following some of your questions and have no answers > yet, but what exactly is your mirror environment (IPs)? > > Sent from Janet's iPad > > -Al- > > On Nov 23, 2016, at 7:10 PM, Tsutomu Oyamada wrote: > > Hi, All. > > > > We know CVD version information is published in DNS TXT record, this > > record's TTL values, 1800 seconds is currently is. This value is the > > same from the previous? > > > > Also in freshclam download old versions of CVD(one day ago) in local > > mirror environment, we will succeed. > > > > I thought I was bound to fail. > > > > Why not? > > > > T.O > ___ > clamav-users mailing list > clamav-users@lists.clamav.net > http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users > > > Help us build a comprehensive ClamAV guide: > https://github.com/vrtadmin/clamav-faq > > http://www.clamav.net/contact.html#ml > ___ clamav-users mailing list clamav-users@lists.clamav.net http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
Re: [clamav-users] TTL of DNS recode
Thank for that very thorough explanation. I learned a lot. But I suspect only somebody from ClamAV can answer the OP question about this, although I don't really understand why it's being asked (i.e. if it was changed, what impact could it have on the OP or was it simply asked out of curiosity?), -Al- On Thu, Nov 24, 2016 at 12:11 AM, Simon Hobson wrote: > > Al Varnell wrote: > >> So I think I have the answer for this one. From my research it would seem >> that TTL values are set by the DNS server you are accessing, not by the >> ClamAV and is the same for all records on that server. You would have to >> check with the DNS ISP to find out if it has changed or not. > > OK, there seems to be some confusion about how DNS works and what the TTL > value does, and what lookups report. Dennis has sort of covered some of this, > but it might help to see the whole process. > > When you do a lookup for a name, your client asks the locally configured > resolver the question - eg what is the TXT record for current.cvd.clamav.net. > > Assuming the resolver has nothing in the cache, then it will go to the root > servers and ask the same question. The root servers won't know, so they will > reply to the effect of "I don't know, but the name servers > have a better answer" - ie the name servers for .net > So your resolver goes and asks the same question of one or more of those > servers. They'll get the same "I don't know, but ..." answer, this time with > a list of name servers handling clamav.net. > The resolver will continue in this manner until it reaches far enough down > the tree to get find a server that knows the answer. In this case, the > nameservers for clamav.net (ns[2-7].clamav.net here*) know the answer and > will return it. > > Using DIG, this is the chain of results, note that when using +trace, DIG > deliberately ignores cached records and so the TTL values are those of the > records as served by the relevant name server (except for the root servers > which I assume it still uses the local resolver cache for - it has to start > somewhere !) : > > $ dig +trace current.cvd.clamav.net txt > > ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +trace current.cvd.clamav.net txt > ;; global options: +cmd > . 45003 IN NS h.root-servers.net. > . 45003 IN NS b.root-servers.net. > . 45003 IN NS l.root-servers.net. > . 45003 IN NS e.root-servers.net. > . 45003 IN NS g.root-servers.net. > . 45003 IN NS m.root-servers.net. > . 45003 IN NS j.root-servers.net. > . 45003 IN NS c.root-servers.net. > . 45003 IN NS i.root-servers.net. > . 45003 IN NS a.root-servers.net. > . 45003 IN NS d.root-servers.net. > . 45003 IN NS f.root-servers.net. > . 45003 IN NS k.root-servers.net. > ;; Received 508 bytes from 192.168.0.33#53(192.168.0.33) in 21 ms > > net. 172800 IN NS e.gtld-servers.net. > net. 172800 IN NS m.gtld-servers.net. > net. 172800 IN NS f.gtld-servers.net. > net. 172800 IN NS a.gtld-servers.net. > net. 172800 IN NS l.gtld-servers.net. > net. 172800 IN NS b.gtld-servers.net. > net. 172800 IN NS j.gtld-servers.net. > net. 172800 IN NS c.gtld-servers.net. > net. 172800 IN NS d.gtld-servers.net. > net. 172800 IN NS h.gtld-servers.net. > net. 172800 IN NS k.gtld-servers.net. > net. 172800 IN NS g.gtld-servers.net. > net. 172800 IN NS i.gtld-servers.net. > ;; Received 509 bytes from 2001:7fe::53#53(2001:7fe::53) in 43 ms > > clamav.net. 172800 IN NS ns3.clamav.net. > clamav.net. 172800 IN NS ns4.clamav.net. > clamav.net. 172800 IN NS ns7.clamav.net. > clamav.net. 172800 IN NS ns6.clamav.net. > clamav.net. 172800 IN NS ns4a.clamav.net. > clamav.net. 172800 IN NS ns1a.clamav.net. > ;; Received 302 bytes from 192.42.93.30#53(192.42.93.30) in 44 ms > > current.cvd.clamav.net. 1800IN TXT > "0.99.2:57:22593:1479972755:1:63:45272:285" > cvd.clamav.net. 7200IN NS ns3.clamav.net. > cvd.clamav.net. 7200IN NS ns4.clamav.net. > cvd.clamav.net. 7200IN NS ns5.clamav.net. > cvd.clamav.net. 7200IN NS
Re: [clamav-users] TTL of DNS recode
Al Varnell wrote: > So I think I have the answer for this one. From my research it would seem > that TTL values are set by the DNS server you are accessing, not by the > ClamAV and is the same for all records on that server. You would have to > check with the DNS ISP to find out if it has changed or not. OK, there seems to be some confusion about how DNS works and what the TTL value does, and what lookups report. Dennis has sort of covered some of this, but it might help to see the whole process. When you do a lookup for a name, your client asks the locally configured resolver the question - eg what is the TXT record for current.cvd.clamav.net. Assuming the resolver has nothing in the cache, then it will go to the root servers and ask the same question. The root servers won't know, so they will reply to the effect of "I don't know, but the name servers have a better answer" - ie the name servers for .net So your resolver goes and asks the same question of one or more of those servers. They'll get the same "I don't know, but ..." answer, this time with a list of name servers handling clamav.net. The resolver will continue in this manner until it reaches far enough down the tree to get find a server that knows the answer. In this case, the nameservers for clamav.net (ns[2-7].clamav.net here*) know the answer and will return it. Using DIG, this is the chain of results, note that when using +trace, DIG deliberately ignores cached records and so the TTL values are those of the records as served by the relevant name server (except for the root servers which I assume it still uses the local resolver cache for - it has to start somewhere !) : $ dig +trace current.cvd.clamav.net txt ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +trace current.cvd.clamav.net txt ;; global options: +cmd . 45003 IN NS h.root-servers.net. . 45003 IN NS b.root-servers.net. . 45003 IN NS l.root-servers.net. . 45003 IN NS e.root-servers.net. . 45003 IN NS g.root-servers.net. . 45003 IN NS m.root-servers.net. . 45003 IN NS j.root-servers.net. . 45003 IN NS c.root-servers.net. . 45003 IN NS i.root-servers.net. . 45003 IN NS a.root-servers.net. . 45003 IN NS d.root-servers.net. . 45003 IN NS f.root-servers.net. . 45003 IN NS k.root-servers.net. ;; Received 508 bytes from 192.168.0.33#53(192.168.0.33) in 21 ms net.172800 IN NS e.gtld-servers.net. net.172800 IN NS m.gtld-servers.net. net.172800 IN NS f.gtld-servers.net. net.172800 IN NS a.gtld-servers.net. net.172800 IN NS l.gtld-servers.net. net.172800 IN NS b.gtld-servers.net. net.172800 IN NS j.gtld-servers.net. net.172800 IN NS c.gtld-servers.net. net.172800 IN NS d.gtld-servers.net. net.172800 IN NS h.gtld-servers.net. net.172800 IN NS k.gtld-servers.net. net.172800 IN NS g.gtld-servers.net. net.172800 IN NS i.gtld-servers.net. ;; Received 509 bytes from 2001:7fe::53#53(2001:7fe::53) in 43 ms clamav.net. 172800 IN NS ns3.clamav.net. clamav.net. 172800 IN NS ns4.clamav.net. clamav.net. 172800 IN NS ns7.clamav.net. clamav.net. 172800 IN NS ns6.clamav.net. clamav.net. 172800 IN NS ns4a.clamav.net. clamav.net. 172800 IN NS ns1a.clamav.net. ;; Received 302 bytes from 192.42.93.30#53(192.42.93.30) in 44 ms current.cvd.clamav.net. 1800IN TXT "0.99.2:57:22593:1479972755:1:63:45272:285" cvd.clamav.net. 7200IN NS ns3.clamav.net. cvd.clamav.net. 7200IN NS ns4.clamav.net. cvd.clamav.net. 7200IN NS ns5.clamav.net. cvd.clamav.net. 7200IN NS ns6.clamav.net. cvd.clamav.net. 7200IN NS ns7.clamav.net. ;; Received 184 bytes from 2a01:4f8:160:8421::2#53(2a01:4f8:160:8421::2) in 38 ms Naturally it would be wasteful if the resolver did all these lookups every time, so it stores all the results it gets back in a local cache. So next time you lookup the same answer, it already has it. If you lookup a different .net address, it already knows which servers handle .net. And so on. So what is the TTL
