Stowage/clamav
2
0
Fork 0
mirror of https://github.com/Cisco-Talos/clamav.git synced 2025-10-19 10:23:17 +00:00
Code Issues Projects Releases Packages Wiki Activity

Docker: milter daemon, news, docs, github action

Browse source 
The milter default was not set correctly so it was starting
clamav-milter by default. Added default true/false settings for each of
the docker daemon environment variables.

Added command to entrypoint to change database directory ownership to
the clamav user, in case it is a mounted volume (which get root ownership
by default).

Removed the clamav user & group from the build image, as it isn't needed
until the base image.

Added announcement details and acknowledgements to the News document.

Added details to the Docker Readme describing:

- the tag naming convention
- how to mount database volumes
- various other tweaks

Fixed the path for the update script in the GitHub Action, and changed
from alpine-latest to ubuntu-latest, because alpine-latest doesn't seem
to be an option.
This commit is contained in:
Micah Snyder 2021-04-29 17:40:12 -07:00
parent 21a4d59fce
commit 6d3685c421
7 changed files with 360 additions and 139 deletions
Download patch file Download diff file Expand all files Collapse all files

15
.github/workflows/docker-db-update.yml vendored Normal file
View file

@ -0,0 +1,15 @@
name: Docker image virus database update
on:
schedule:
- cron: '0 0 1 * *'
jobs:
update-image-databases:
runs-on: ubuntu-latest
env:
CLAMAV_DOCKER_USER: ${{ secrets.CLAMAV_DOCKER_USER }}
CLAMAV_DOCKER_PASSWD: ${{ secrets.CLAMAV_DOCKER_PASSWD }}
steps:
- name: Update virus database and push image
run: ./dockerfiles/update_db_image.sh

16
.github/workflows/docker_virusdb-update.yml vendored
View file

@ -1,16 +0,0 @@
name: Docker image virus database update
on:
schedule:
- cron: "0 0 1 * *"
jobs:
Release_virusdb_update:
runs-on: alpine-latest
steps:
- name: Release update virus database and push image
env:
CLAMAV_DOCKER_PASSWD: "${{ secrets.CLAMAV_DOCKER_PASSWD }}"
CLAMAV_DOCKER_USER: "${{ secrets.CLAMAV_DOCKER_USER }}"
run: "dockerfiles/release_db_update.sh"

6
Dockerfile
View file

@ -40,11 +40,7 @@ RUN apk add --no-cache \
py3-pytest \
zlib-dev \
&& \
addgroup -S "clamav" && \
adduser -D -G "clamav" -h "/var/lib/clamav" -s "/bin/false" -S "clamav" && \
install -d -m 755 -g "clamav" -o "clamav" "/var/log/clamav" && \
mkdir -p "./build" && \
cd "./build" && \
mkdir -p "./build" && cd "./build" && \
cmake .. \
-DCMAKE_BUILD_TYPE="Release" \
-DCMAKE_INSTALL_PREFIX="/usr" \

38
NEWS.md
View file

@ -21,6 +21,43 @@ ClamAV 0.104.0 includes the following improvements and changes.
to be removed in the next feature release. The Visual Studio build system has
been removed.
- There are now official ClamAV images on Docker Hub.
You can find the images on [Docker Hub under `clamav`](https://hub.docker.com/r/clamav/clamav).
Docker Hub ClamAV tags:
- `clamav/clamav:<version>`: A release preloaded with signature databases.
Using this container will save the ClamAV project some bandwidth.
Use this if you will keep the image around so that you don't download the
entire database set every time you start a new container. Updating with
FreshClam from existing databases set does not use much data.
- `clamav/clamav:<version>_base`: A release with no signature databases.
Use this container **only** if you mount a volume in your container under
`/var/lib/clamav` to persist your signature database databases.
This method is the best option because it will reduce data costs for ClamAV
and for the Docker registry, but it does require advanced familiarity with
Linux and Docker.
> _Caution_: Using this image without mounting an existing database
directory will cause FreshClam to download the entire database set each
time you start a new container.
You can use the `unstable` version (i.e. `clamav/clamav:unstable` or
`clamav/clamav:unstable_base`) to try the latest from our development branch.
Please, be kind when using 'free' bandwidth, both for the virus databases
but also the Docker registry. Try not to download the entire database set or
the larger ClamAV database images on a regular basis.
For more details, see
[the ClamAV Docker documentation](https://github.com/Cisco-Talos/clamav-devel/blob/main/README.Docker.md).
Special thanks to Olliver Schinagl for his excellent work creating ClamAV's
new Docker files, image database deployment tooling, and user documentation.
### Notable changes
The following was added in 0.103.1 and is repeated here for awareness, as
@ -65,6 +102,7 @@ The ClamAV team thanks the following individuals for their code submissions:
- Brian Bergstrand
- cw2k
- Duane Waddle
- Olliver Schinagl
- Orion Poplawski
- Sergey Valentey
- Sven Rueß

413
README.Docker.md
View file

@ -2,60 +2,172 @@
ClamAV can be run within a Docker container. This provides isolation from other
processes by running it in a containerized environment. If new or unfamiliar
with docker, containers or cgroups see [docker.com](https://www.docker.com).
with Docker, containers or cgroups see [docker.com](https://www.docker.com).
## The official images on Docker Hub
ClamAV image tags [on Docker Hub](https://hub.docker.com/u/clamav/clamav)
follow this naming convention:
- `clamav/clamav:<version>`: A release preloaded with signature databases.
Using this container will save the ClamAV project some bandwidth.
Use this if you will keep the image around so that you don't download the
entire database set every time you start a new container. Updating with
FreshClam from existing databases set does not use much data.
- `clamav/clamav:<version>_base`: A release with no signature databases.
Use this container **only** if you mount a volume in your container under
`/var/lib/clamav` to persist your signature database databases.
This method is the best option because it will reduce data costs for ClamAV
and for the Docker registry, but it does require advanced familiarity with
Linux and Docker.
> _Caution_: Using this image without mounting an existing database
directory will cause FreshClam to download the entire database set each
time you start a new container.
You can use the `unstable` version (i.e. `clamav/clamav:unstable` or
`clamav/clamav:unstable_base`) to try the latest from our development branch.
## Building the ClamAV image
While it is recommended to pull the image from our
[docker hub registry](https://hub.docker.com/u/clamav/clamav), some may want
to build the image locally instead. All that is needed is
```console
[Docker Hub registry](https://hub.docker.com/u/clamav/clamav), some may want
to build the image locally instead. All that is needed is:
```bash
docker build --tag "clamav:TICKET-123" .
```
in the current directory. This will build the ClamAV image and tag it with
the name "clamav:TICKET-123". Any name can generally be used and it is this
name that needs to be referred to later when running the image.
## Running clamd
## Running ClamD
To run `clamd` in a docker container, first, an image either has to be built
or pulled from a docker registry. To pull ClamAV from the official docker hub
registry, the following command can be used.
To run `clamd` in a Docker container, first, an image either has to be built
or pulled from a Docker registry.
> _Note_: Pulling is not always required, as `docker run` also pulls the image
> if it does not yet exist and `docker run --pull` will always pull beforehand
> to ensure the most up-to-date container is being used.
### Running ClamD using the official ClamAV images from Docker Hub
```console
docker run \
--interactive \
--name "clam_container_01" \
--rm \
--tty \
"myclamav" --help
To pull the ClamAV "unstable" image from Docker Hub, run:
```bash
docker pull clamav/clamav:unstable
```
The above creates an interactive container with the current tty connected to
it. This is optional but useful when getting started as it allows one to
directly see the output and, in the case of `clamd`, send ctrl-c to close the
container. The `--rm` parameter ensures the container is cleaned up again after
it exists and the `--name` parameter names the container, so it can be
referenced through other (docker) commands, as several containers of the same
image "myclamav" can be started without conflicts.
> _Tip_: Substitute `unstable` with a different version as needed.
## Running clam(d)scan
To pull _and run_ the official ClamAV images from the Docker Hub registry,
try the following command:
```bash
docker run \
--interactive \
--tty \
--rm \
--name "clam_container_01" \
clamav/clamav:unstable
```
The above creates an interactive container with the current TTY connected to
it. This is optional but useful when getting started as it allows one to
directly see the output and, in the case of `clamd`, send `ctrl-c` to close the
container. The `--rm` parameter ensures the container is cleaned up again after
it exits and the `--name` parameter names the container, so it can be
referenced through other (Docker) commands, as several containers of the same
image can be started without conflicts.
> _Note_: Pulling is not always required. `docker run` will pull the image
if it cannot be found locally. `docker run --pull always` will always pull
beforehand to ensure the most up-to-date container is being used.
Do not use `--pull always` with the larger ClamAV images.
> _Tip_: It's common to see `-it` instead of `--interactive --tty`.
### Running ClamD using a Locally Built Image
You can run a container using an image built locally
([see "Building the ClamAV Image"](#building-the-clamav-image)). Just run:
```bash
docker run -it --rm \
--name "clam_container_01" \
clamav:TICKET-123
```
### Persisting the virus database (volume)
The virus database in `/var/lib/clamav` is by default unique to each container
and thus is normally not shared. For simple setups this is fine, where only one
instance of `clamd` is expected to run in a dockerized environment. However
some use cases may want to efficiently share the database or at least persist
it across short-lived ClamAV containers.
To do so, you have two options:
1. Create a [Docker volume](https://docs.docker.com/storage/volumes/) using the
`docker volume` command.
Volumes are completely managed by Docker and are the best choice for
creating a persistent database volume.
For example, create a "clam_db" volume:
```bash
docker volume create clam_db
```
Then start one or more containers using this volume. The first container
to use a new database volume will download the full database set. Subsequent
containers will use the existing databases and may update them as needed:
```bash
docker run -it --rm \
--name "clam_container_01" \
--mount source=clam_db,target=/var/lib/clamav \
clamav/clamav:unstable_base
```
2. Create a [Bind Mount](https://docs.docker.com/storage/bind-mounts/) that
maps a file system directory to a path within the container.
Bind Mounts depend on the directory structure, permissions, and operating
system of the Docker host machine.
Run the container with these arguments to mount the a directory from your host
environment as a volume in the container.
```bash
--mount type=bind,source=/path/to/databases,target=/var/lib/clamav
```
When doing this, it's best to use the `<version>_base` image tags so as to
save on bandwith. E.g.:
```bash
docker run -it --rm \
--name "clam_container_01" \
--mount type=bind,source=/path/to/databases,target=/var/lib/clamav \
clamav/clamav:unstable_base
```
> _Disclaimer_: When using a Bind Mount, the container's entrypoint script
will change ownership of this directory to its "clamav" user. This enables
FreshClam and ClamD with the required permissions to read and write to the
directory, though these changes will also affect those files on the host.
If you're thinking about running multiple containers that share a single
database volume, [here are some notes on how this might work](#multiple-containers-sharing-the-same-mounted-databases).
## Running Clam(D)Scan
Scanning files using `clamscan` or `clamdscan` is possible in various ways with
docker. This section briefly describes them, but the other sections of this
Docker. This section briefly describes them, but the other sections of this
document are best read before hand to better understand some of the concepts.
One important aspect is however to realize that docker by default does not have
access to any of the hosts files. And so to scan these within docker, they need
to be volume mounted to be made accessible.
One important aspect is however to realize that Docker by default does not have
access to any of the hosts files. And so to scan these within Docker, they need
to be mounted with a [bind mount](https://docs.docker.com/storage/bind-mounts/)
to be made accessible.
For example, running the container with these arguments ...
```console
--volume '/path/to/scan:/scandir'
```bash
--mount type=bind,source=/path/to/scan,target=/scandir
--mount type=bind,source=/path/to/scan,target=/scandir
```
... would make the hosts file/directory `/path/to/scan` available in the
container as `/scandir` and thus invoking `clamscan` would thus be done on
@ -65,77 +177,98 @@ Note that while technically possible to run either scanners via `docker exec`
this is not described as it is unlikely the container has access to the files
to be scanned.
### clamscan
### ClamScan
Using `clamscan` outside of the docker container is how normally `clamscan` is
Using `clamscan` outside of the Docker container is how normally `clamscan` is
invoked. To make use of the available shared dockerized resources however, it
is possible to expose the virus database and share that for example. E.g. it
could be possible to run a docker container with only `freshclamd` and share
the virus database directory `/var/lib/clamav`. This could be useful for file
servers for example, where only `clamscan` is installed on the host, and
`freshclam` is managed in a docker container.
could be possible to run a Docker container with only the `freshclam` daemon
running, and share the virus database directory `/var/lib/clamav`. This could
be useful for file servers for example, where only `clamscan` is installed on
the host, and `freshclam` is managed in a Docker container.
> _Note_: Running `freshclamd` separated from `clamd` is less recommended,
> unless the `clamd` socket is shared with `freshclam` as `freshclam` would
> not be able to inform `clamd` of database updates.
> _Note_: Running the `freshclam` daemon separated from `clamd` is less
recommended, unless the `clamd` socket is shared with `freshclam` as
`freshclam` would not be able to inform `clamd` of database updates.
### Dockerized clamscan
### Dockerized ClamScan
To run `clamscan` in a docker container, the docker container can be invoked
To run `clamscan` in a Docker container, the Docker container can be invoked
as:
```console
docker run \
--interactive \
--rm \
--tty \
--volume '/path/to/scan:/scandir' \
"myclamav" clamscan /scandir
```bash
docker run -it --rm \
--mount type=bind,source=/path/to/scan,target=/scandir \
clamav/clamav:unstable \
clamscan /scandir
```
This would pull the virus database using `freshclam`, run the scan and cleanup.
> _Note_: This is very inefficient when done often, as the complete database is
> downloaded on each invocation.
However, this will use whatever signatures are found in the image, which may be
slightly out of date. If using `clamscan` in this way, it would be best to use
a [database volume](#running-with-a-mounted-database-directory-volume) that is
up-to-date so that you scan with the latest signatures. E.g.:
```bash
docker run -it --rm \
--mount type=bind,source=/path/to/scan,target=/scandir \
--mount type=bind,source=/path/to/databases,target=/var/lib/clamav \
clamav/clamav:unstable_base \
clamscan /scandir
```
### clamdscan
### ClamDScan
As with `clamscan`, `clamdscan` can also be run when installed on the host, by
connecting to the dockerized `clamd`. This can be done by either pointing
`clamdscan` to the exposed TCP/UDP port or unix socket.
### Dockerized clamdscan
### Dockerized ClamDScan
Running both `clamd` and `clamdscan` is also easily possible, as all that is
needed is the shared socket between the two containers. The only cavaet here
is to mount the files to be scaned in the container that is expected to run
`clamdscan`.
is to:
1. mount the files to be scanned in the container that will run `clamd`, or
2. mount the files to be scanned in the container that will `clamdscan` run if
using `clamdscan --stream`. The `--stream` option will be slower, but
enables submitting files from a different machine on a network.
For example:
```console
docker run \
--interactive \
--rm \
--tty \
--volume '/path/to/scan:/scandir' \
--volume '/var/lib/docker/data/clamav/sockets/:/run/clamav/'
"myclamav" clamdscan /scandir
```bash
docker run -it --rm \
--mount type=bind,source=/path/to/scan,target=/scandir \
--mount type=bind,source=/var/lib/docker/data/clamav/sockets/,target=/run/clamav/
clamav/clamav:unstable
```
```bash
docker run -it --rm \
--mount type=bind,source=/path/to/scan,target=/scandir \
--mount type=bind,source=/var/lib/docker/data/clamav/sockets/,target=/run/clamav/
clamav/clamav:unstable_base \
clamdscan /scandir
```
## Controlling the container
The ClamAV container actually runs both `freshclamd` and `clamd` by default.
Optionally available to the container is also ClamAV's milter. To control the
behavior of the services started within the container, the following flags can
be passed to the `docker run` command with the `--environment` parameter.
The ClamAV container actually runs both `freshclam` and `clamd` daemons by
default. Optionally available to the container is ClamAV's milter daemon.
To control the behavior of the services started within the container, the
following flags can be passed to the `docker run` command with the
`--env` (`-e`) parameter.
* CLAMAV_NO_CLAMD [true|**false**] Do not start `clamd` (default: start `clamd`)
* CLAMAV_NO_FRESHCLAMD [true|**false**] Do not start `freshclamd` (default: start `freshclamd`)
* CLAMAV_NO_MILTERD [**true**|false] Do not start `clamav-milter` (default: nomilter)
* CLAMD_STARTUP_TIMEOUT [integer] Seconds to wait for `clamd` to start (default: 1800)
* FRESHCLAM_CHECKS [integer] `freshclam` daily update frequency (default: once per day)
* CLAMAV_NO_CLAMD [true|**false**] Do not start `clamd`.
(default: start `clamd`)
* CLAMAV_NO_FRESHCLAMD [true|**false**] Do not start the `freshclam` daemon.
(default: start the `freshclam` daemon)
* CLAMAV_NO_MILTERD [**true**|false] Do not start the `clamav-milter` daemon.
(default: start the `clamav-milter` daemon )
* CLAMD_STARTUP_TIMEOUT [integer] Seconds to wait for `clamd` to start.
(default: 1800)
* FRESHCLAM_CHECKS [integer] `freshclam` daily update frequency.
(default: once per day)
So to additionally also enable `clamav-milter`, the following flag can be added:
```console
--environment 'CLAMAV_NO_MILTERED=false'
So to additionally also enable `clamav-milter`, the following flag can be
added:
```bash
--env 'CLAMAV_NO_MILTERED=false'
```
Further more, all of the configuration files that live in `/etc/clamav` can be
@ -143,15 +276,15 @@ overridden by doing a volume-mount to the specific file. The following argument
can be added for this purpose. The example uses the entire configuration
directory, but this can be supplied multiple times if individual files deem to
be replaced.
```console
--volume '/full/path/to/clamav/:/etc/clamav'
```bash
--mount type=bind,source=/full/path/to/clamav/,target/etc/clamav
```
> _Note_: Even when disabling `freshclamd`, `freshclam` will always run at
> least once during container startup if there is no virus database. While not
> recommended, the virus database location itself `/var/lib/clamav/` could be
> a persistent docker volume. This however is slightly more advanced and out of
> scope of this document.
> _Note_: Even when disabling the `freshclam` daemon, `freshclam` will always
run at least once during container startup if there is no virus database.
While not recommended, the virus database location itself `/var/lib/clamav/`
could be a persistent Docker volume. This however is slightly more advanced
and out of scope of this document.
## Connecting to the container
@ -161,19 +294,19 @@ To connect to a running ClamAV container, `docker exec` can be used to run a
command on an already running container. To do so, the name needs to be either
obtained from `docker ps` or supplied during container start via the `--name`
parameter. The most interesting command in this case can be `clamdtop`.
```console
```bash
docker exec --interactive --tty "clamav_container_01" clamdtop
```
Alternatively, a shell can be started to inspect and run commands within the
container as well.
```console
```bash
docker exec --interactive --tty "clamav_container_01" /bin/sh
```
### Unix sockets
The default socket for `clamd` is located inside the container as
`/run/clamav/clamd.sock` and can be connected to when exposed via a docker
`/run/clamav/clamd.sock` and can be connected to when exposed via a Docker
volume mount. To ensure, that `clamd` within the container can freely create
and remove the socket, the path for the socket is to be volume-mounted, to
expose it for others on the same host to use. The following volume can be used
@ -181,13 +314,13 @@ for this purpose. Do ensure that the directory on the host actually exists and
clamav inside the container has permission to access it.
Caution is required when managing permissions, as incorrect permission could
open clamd for anyone on the host system.
```console
--volume '/var/lib/docker/data/clamav/sockets/:/run/clamav/'
```bash
--mount type=bind,source=/var/lib/docker/data/clamav/sockets/,target=/run/clamav/
```
With the socket exposed to the host, any other service can now talk to `clamd`
as well. If for example `clamdtop` where installed on the local host, calling
```console
```bash
clamdtop "/var/lib/docker/data/clamav/sockets/clamd.sock"
```
should work just fine. Likewise, running `clamdtop` in a different container,
@ -197,52 +330,49 @@ connect a mail server to `clamd`.
### TCP
While `clamd` and `clamav-milter` will listen on the default TCP ports as per
configuration directives, docker does not expose these by default to the host.
Only within containers can these ports be accessed. To expose, or publish,
ClamAV in the official Docker images is configured to listen for TCP
connections on these ports:
- `clamd`: 3310
- `clamav-milter`: 7357
While `clamd` and `clamav-milter` will listen on the above TCP ports, Docker
does not expose these by default to the host.
Only within containers can these ports be accessed. To expose, or "publish",
these ports to the host, and thus potentially over the (inter)network, the
`--publish` (or `--publish-all`) flag to `docker run` can be used. While more
advanced/secure mappings can be done as per documentation, the basic way is to
`--publish [<host_port>:]<container_port>` to make the port available to the
host.
```console
--publish 73310:3310 \
--publish 7357
```bash
--publish 73310:3310 \
--publish 7357
```
The above would thus publish the milter port 3310 as 73310 on the host and the
clamd port 7357 as a random to the host. The random port can be inspected via
`docker ps`.
> **Warning** extreme caution is to be taken when using `clamd` over TCP as
> there are no protections on that level. All traffic is un-encrypted. Extra
> care is to be taken when using TCP communications.
> **Warning**: Extreme caution is to be taken when using `clamd` over TCP as
there are no protections on that level. All traffic is un-encrypted. Extra
care is to be taken when using TCP communications.
## Virus database
The virus database in `/var/lib/clamav` is by default unique to each container
and thus is normally not shared. For simple setups this is fine, where only one
instance of `clamd` is expected to run in a dockerized environment. However
some use cases may want to efficiently share the database. To do so, the
`docker volume` command can be used to create a persistent virus database.
## Container clamd healthcheck
## Container ClamD health-check
Docker has the ability to run simple `ping` checks on services running inside
containers. If `clamd` is running inside the container, docker will on
containers. If `clamd` is running inside the container, Docker will on
occasion send a `ping` to `clamd` on the default port and wait for the pong
from `clamd`. If `clamd` fails to respond, docker will treat this as an error.
from `clamd`. If `clamd` fails to respond, Docker will treat this as an error.
The healthcheck results can be viewed with `docker inspect`.
## Performance
The performance impact of running `clamd` in docker is negligible. Docker is
The performance impact of running `clamd` in Docker is negligible. Docker is
in essence just a wrapper around Linux's cgroups and cgroups can be thought of
as `chroot` or FreeBSD's `jail`. All code is executed on the host without any
translation. Docker does however do some isolation (through cgroups) to isolate
the various systems somewhat.
Of course, nothing in life is free, and so there is some overhead. Disk-space
being the most prominent one. The docker container might have some duplication
being the most prominent one. The Docker container might have some duplication
of files for example between the host and the container. Further more, also RAM
memory may be duplicated for each instance, as there is no RAM-deduplication.
Both of which can be solved on the host however. A filesystem that supports
@ -257,5 +387,60 @@ this writing.
## Bandwidth
Please, be kind when using 'free' bandwidth. Both for the virus databases
but also the docker registry.
Please, be kind when using 'free' bandwidth, both for the virus databases
but also the Docker registry. Try not to download the entire database set or
the larger ClamAV database images on a regular basis.
## Advanced container configurations
### Multiple containers sharing the same mounted databases
You can run multiple containers that share the same database volume, but be
aware that the FreshClam daemons on each would compete to update the databases.
Most likely, one would update the databases and trigger its ClamD to load the
new databases, while the others would be oblivious to the new databases and
would continue with the old signatures until the next ClamD self-check.
This is fine, honestly. It won't take that long before the new signatures are
detected by ClamD's self-check and the databases are reloaded automatically.
To reload the databases on all ClamD containers immediately after an update,
you could [disable the FreshClam daemon](#controlling-the-container) when you
start the containers. Later, use `docker exec` to perform an update and again
as needed to have ClamD load updated databases.
> _Note_: This really isn't necessary but you could do this if you wish.
Exactly how you orchestrate this will depend on your environment.
You might do something along these lines:
1. Create a "clam_db" volume, if you don't already have one:
```bash
docker volume create clam_db
```
2. Start your containers:
```bash
docker run -it --rm \
--name "clam_container_01" \
--mount source=clam_db,target=/var/lib/clamav \
--env 'CLAMAV_NO_FRESHCLAMD=true' \
clamav/clamav:unstable_base
```
Wait for the first one to download the databases (if it's a new database
volume). Then start more:
```bash
docker run -it --rm \
--name "clam_container_02" \
--mount source=clam_db,target=/var/lib/clamav \
--env 'CLAMAV_NO_FRESHCLAMD=true' \
clamav/clamav:unstable_base
```
3. Check for updates, as needed:
```bash
docker exec -it clam_container_01 freshclam --on-update-execute=EXIT_1 || \
if [ $? == 1 ]; then \
docker exec -it clam_container_01 clamdscan --reload; \
docker exec -it clam_container_02 clamdscan --reload; \
fi
```

2
README.md
View file

@ -36,7 +36,7 @@ to get started!
### Docker
ClamAV can be run using Docker, see [README.Docker.md](README.Docker.md) and
our images on [docker hub](https://hub.docker.com/r/clamav/clamav).
our images on [Docker Hub](https://hub.docker.com/r/clamav/clamav).
#### Build from Source

9
dockerfiles/docker-entrypoint.sh
View file

@ -14,6 +14,9 @@ if [ ! -d "/run/clamav" ]; then
install -d -g "clamav" -m 775 -o "clamav" "/run/clamav"
fi
# Assign ownership to the database directory, just in case it is a mounted volume
chown -R clamav:clamav /var/lib/clamav
# run command if it is not starting with a "-" and is an executable in PATH
if [ "${#}" -gt 0 ] && \
[ "${1#-}" = "${1}" ] && \
@ -38,7 +41,7 @@ else
freshclam --foreground --stdout
fi
if [ "${CLAMAV_NO_CLAMD:-}" != "true" ]; then
if [ "${CLAMAV_NO_CLAMD:-false}" != "true" ]; then
echo "Starting ClamAV"
if [ -S "/run/clamav/clamd.sock" ]; then
unlink "/run/clamav/clamd.sock"
@ -57,7 +60,7 @@ else
echo "socket found, clamd started."
fi
if [ "${CLAMAV_NO_FRESHCLAMD:-}" != "true" ]; then
if [ "${CLAMAV_NO_FRESHCLAMD:-false}" != "true" ]; then
echo "Starting Freshclamd"
freshclam \
--checks="${FRESHCLAM_CHECKS:-1}" \
@ -68,7 +71,7 @@ else
&
fi
if [ "${CLAMAV_NO_MILTERD:-}" != "true" ]; then
if [ "${CLAMAV_NO_MILTERD:-true}" != "true" ]; then
echo "Starting clamav milterd"
clamav-milter &
fi