Mailing List Archive

Scott,

First - "clamd" is the daemon. It starts up and parses / loads all the
virus definitions into memory, then clamdscan (or other programs)
interact with it (via local unix socket) to scan files.

I checked my CentOS 7 server and I'm not seeing all those packages you
mentioned. Do you have other repos enabled too? It looks like the
systemd service files have been consolidated into the relevant other
RPMs.

All I see from epel is as follows:

clamav - Provides the basic scanning programs (i.e. clamscan & others)
and documentation.
clamav-data - Contains the 3 main official virus databases. (These
should be updated regularly via freshclam)
clamav-devel - headerfiles and libraries for developing other apps
(you don't need -devel packages for normal usage, they are for
"development")
clamav-filesystem - Looks just like it has some filesystem structure,
not sure WTF is going on with that...
clamav-lib - Typical dynamic libraries that other applications might use.
clamav-milter - Files for running a milter with your mail server.
clamav-update - The freshclam application, documentation, and such.
This program updates the virus definitions.
clamd - The ClamAV daemon.

clamav-unofficial-sigs - Not part of the main ClamAV package. This is
a 3rd party script, that in turn downloads 3rd party definition files.

If you want to see files within an RPM, the description, and all that
good stuff there are numerous websites with searchable databases.
However my favorite is probably: https://pkgs.org/

So, to answer your question. If you aren't building 3rd party
applications, the you can skip installing 'clamav-devel' as that will
just take up space. If you are not going to implement it directly into
your email server that uses the milter interface, then you can skip
'clamav-milter'. (Some 3rd party programs like spamassassin scan files
via the Clamav's unix socket).

Not sure about on-access scanning, I would assume it would require
clamd... that's something I'm sure the documentation explains more
in-depth.

What you want to scan depends on what you want to protect, who has
access, what the machine's use is, etc.... Please don't blindly set
it to '/'... Think about certain parts that would not respond well if
you tried to always scan on access... i.e.: /dev, /proc,
high-transaction / large database files, log files, and possibly any
remote-mounted sources...

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Hi there,

On Wed, 28 Aug 2019, Scott A. Wozny via clamav-users wrote:

> I?m looking at installing Clam on my CentOS 7 servers ...

Sorry, but I have to ask :)

Why?

> sites offering install tutorials recommend installing

Hmmmm. Sites with tutorials. I guess I avoid them.

> clamav-server clamav-data clamav-update clamav-filesystem clamav
> clamav-scanner-systemd clamav-devel clamav-lib AND
> clamav-server-systemd.

Those are 'packages' from the OS distributions, created and maintained
by the OS distribution maintainers. The ClamAV source (which you'd
get e.g. from the clamav.net site) is a completely different animal.

It's like this:

There are (approximately) two approaches to installing software on a
Linux (or similar Unix-like) box.

Method 1.
---------

You can get the source of the software and build it on the box, using
(and here I abridge, paraphrase and bowdlerize mercilessly) some set
of commands such as, for example, say, perhaps, the ClamAV software:

cd ~/src/
wget http://server.clamav.net/downloads/clamav-0.101.4.tar.gz
tar czvf clamav-0.101.4.tar.gz
cd clamav-0.101.4
./configure
make
su
make install

Now you have ClamAV installed into the places in your system that the
people who produced it decided that it would go when they made that
tarball. You can now delete ~/src/clamav-0.101.4/ and everything in
there, you're done with it. Really.

The result of all this might not be what you want, so you can twiddle
things to put things elsewhere, but don't get involved in that yet.

It also might not work, because there might be things _not_ on your
machine that are needed in order to compile this particular software.
Or indeed _any_ software. You won't get very far without a compiler
for example, and some distributions don't ship with one as standard.

Method 2.
---------

You can install a 'package' from the people who produce your 'flavour'
of Linux, or other OS. You can simply say

apt-get install clamav

and the package tool (in my example APT, but then this is a Debian
box) will not only install clamav (whatever that is) but it will also
install everything that clamav package needs if it isn't already on
the system. Compilers and all the gubbins that goes with them tend to
be BIG. You most likely won't need one if you do it this way because
you'll be installing *binaries* (that have already been compiled for
your system's architecture - i686, AMD64, etc.) from the packages.

This is a lot simpler, and generally recommended if you aren't VERY
familiar with your system. The main trouble is that documentation as
you seem to have discovered is sometimes a bit sparse, so you don't
always know which packages you need in order to do what you want,
always assuming that you know what you want to do in the first place.

Another problem is that OS package maintainers often do strange things
with the packages before they ship them out. They'll almost always
put everything in different locations, so you can have (at least) two
versions of the software on the system: the OS packaged version and
the built from source ('upstream') version. But dont do that unless
you really know what you're doing.

Another problem is that the OS packages are often out of date. For
something like ClamAV, I'd almost always compile from source.

Oh, and Macs are a bit different, but they're basically BSD boxes.
For some reason whenever I play with one, it always seems like I'm
blindfolded, with my hands tied behind my back.

> the official documentation is just to install ClamAV.

The OS distribution packages on the one hand, and ClamAV from the
Sourcefire/Talos/Cisco emporium on the other hand bear no resemblance
to each other, except that the same sources, more or less, were used
to create both.

> So, is there a list of the purpose of each of these packages somewhere?

That's up to the OS people who packaged it.

> ... looks like ClamAV contains all the major pieces (clamav,
> clamav-filesystem, clamav-lib, clamav-update, libtool-ltdl and
> pcre2) EXCEPT for clamd.

It's not like that. If you download for example clamav-0.101.4.tar.gz
from the clamav.net site you get everything you need to get _from_the_
_ClamAV_people_ in the one tarball. But you'll need other stuff too.

You won't get a compiler of course, and you won't get a bunch of 'C'
header files and libraries and stuff which will probably be in those
pesky '-devel' packages we'll talk about later. There's much more.

> I guess my fundamental question is what does clamd do that clamav
> does not and vice versa?

It's not like that. ClamAV includes a thing called a daemon, which
you can start and allow to run indefinitely. It just sits there, in
about a gigabyte of RAM, waiting for you to ask it to scan something.
That daemon is clamd. I'm running two of them on the machine that's
going to send this mail to you - but then it's a mail server. You'd
normally be expected to ask the daemon to scan something by using a
command-line tool like 'clamdscan' or by integrating something like
'clamav-milter' into your mail system. But if you don't want to run
a daemon 24/7 you can just not start it, and instead use the command
line tool 'clamscan' will do something like what 'clamdscan' would do
- but it will first have to load all the signatures, which takes time.

> ... security guy in me wants to avoid installing unneeded applications ...

The security guy in me says at the moment, the biggest threat to your
system is _you_.

> If it helps, my intent is to do both scheduled and on-access scanning

It helps, sort of. I'd still want to know why.

You need clamd for the on-access part unless you won't mind waiting a
couple of minutes for _every_ on-access scan while the scanner process
loads and verifies getting on for ten million signatures.

> I?m considering setting the OnAccessIncludePath to /home and /var.

I'd be more selective than that. Your system logs will be in /var,
for example, and it's most unlikely that they'll represent any kind of
a threat. You'd be far better off learning about them, and trawling
through them whenever you get a spare moment. I'd suggest 'tripwire'
or similar if I thought it was worth the bother but I've found nothing
to beat good hygiene. Are you running a firewall? Do you know what
it's doing? Do you look at the logs?

> would I be better served going ... (perhaps all the way to /)

Don't do that. There are all sorts of bits of the OS that you really
don't want to scan.

> I?m just seeking the benefit of other?s experience in use.

I have experience. I never scan linux boxes with ClamAV. Very rarely
I might mount a Windows filesystem on a Linux box to scan it, but it's
usually better to use Windows tools to do that. They're more flexible
and they're better at it and there are many more of them. If I didn't
run mail servers, I wouldn't bother with ClamAV at all.

> Clamav-scanner-systemd and clamav-server-systemd ...

Talk to the package people about those. I don't use systemd anyway.

> Finally, I see clamav-devel contains a lot of other stuff ...

Anything '-devel' in package terms generally means a bunch of files
which you'll need if you're going to compile something from source.
There might be many such -devel packages needed for any one source
package, it often won't be obvious what they are until the compiler
barks error message at you. Sometimes not even then.

> And, what I hope is my last question...

But you said "finally"! :)

> ... some documents refer to scan.conf and some refer to clamd.conf

The daemon I talked about uses 'clamd.conf'. There are other
configuration files but I have no idea what 'scan.conf' might be
and there is no such file on any of my mail servers.

> Sorry this turned into a novel, but I?d appreciate any insights any
> of you may have.

Take some quality time out to do some reading. Unless you think that
learning stuff can't possibly be a waste of time (something with which
I'd tend to agree), ClamAV _might_ just be using time that could much
better be employed learning about your systems.

I'd have liked to spend more time on this but I have to go.

--

73,
Ged.

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Hi JR.


Thanks for your response. To clarify, I wasn?t referring to clamd, the daemon, I was referring to clamd, the package, which shows up here (I only have the EPEL and base repos installed):


sudo yum install clamav-server

?

Dependencies Resolved


=======================================================================

Package Arch Version Repository Size

=======================================================================

Installing:

clamd x86_64 0.101.4-1.el7 epel 122 k

Installing for dependencies:

clamav-filesystem noarch 0.101.4-1.el7 epel 28 k

clamav-lib x86_64 0.101.4-1.el7 epel 775 k

clamav-update x86_64 0.101.4-1.el7 epel 103 k

libtool-ltdl x86_64 2.4.2-22.el7_3 base 49 k

pcre2 x86_64 10.23-2.el7 base 201 k


Transaction Summary

========================================================================

Install 1 Package (+5 Dependent packages)


But not here:


sudo yum install clamav

?

Dependencies Resolved


========================================================================

Package Arch Version Repository Size

========================================================================

Installing:

clamav x86_64 0.101.4-1.el7 epel 392 k

Installing for dependencies:

clamav-filesystem noarch 0.101.4-1.el7 epel 28 k

clamav-lib x86_64 0.101.4-1.el7 epel 775 k

clamav-update x86_64 0.101.4-1.el7 epel 103 k

libtool-ltdl x86_64 2.4.2-22.el7_3 base 49 k

pcre2 x86_64 10.23-2.el7 base 201 k


Transaction Summary

========================================================================

Install 1 Package (+5 Dependent packages)


Regardless, I did a comparison of both installs on clone machines and it turns out the rpm -ql on each (after they?re installed) show the packages do very different things. It appears that the clamav installer contains the clamav package which includes the clambc, clamconf, clamdscan, clamdtop, clamscan, clamsubmit and sigtool binaries (along with various support files) but NOT the clamd daemon binary while the clamav-server installer contains the clamd package which contains the clamd binary.


This was the source of my original concerns and why I emailed the list in the first place. When I followed the instructions in the RHEL / CentOS section of https://www.clamav.net/documents/installing-clamav that stated (after the epel-release install) that ?yum install -y clamav? was all that was needed to install ClamAV but that process doesn?t leave a clamd daemon anywhere on the system I started looking around the web to see how other people had done it, finding the ?yum -y install clamav-server clamav-data clamav-update clamav-filesystem clamav clamav-scanner-systemd clamav-devel clamav-lib clamav-server-systemd? proposed kitchen-sink installer command, prompting me to email this list and see if anyone had any more detail on what packages did what and seeing if anyone had any suggestions on how to do a usable install because without clamd in the clamav installer and package, the install instructions in the documentation on clamav.net don?t work to produce a usable installation.


I think at this point I have a better understanding of the ClamAV related installers in the EPEL repository and will go do some testing of my use cases.


Oh, and I definitely don?t intend to actually set up scanning from /. I was just looking for ideas as to what should be avoided and why. :)


Thanks for your feedback,


Scott