Bug #6878


how to use snort, squid and squid_guard with a ram disk

Added by sylvain sylvain over 6 years ago. Updated about 6 years ago.

Very Low
Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Affected Version:
Affected Plus Version:
Affected Architecture:


create 2 directories in /root
mkdir /root/sauv_db_clamav/
mkdir /root/sauv_db_squidGuard/

you need to create a file named in /root/ with those commands in it
/bin/mkdir /var/squid
/usr/sbin/chown squid:squid/var/squid
/bin/mkdir /var/squid/acl
/usr/sbin/chown squid:proxy /var/squid/acl
/bin/mkdir /var/squid/lib
/usr/sbin/chown proxy:proxy /var/squid/lib
/bin/mkdir /var/squid/logs
/usr/sbin/chown squid:proxy /var/squid/logs
/bin/mkdir /var/squid/lib/ssl_db
/usr/sbin/chown squid:proxy /var/squid/lib/ssl_db
/bin/mkdir /var/squid/lib/ssl_db/certs
/usr/sbin/chown squid:proxy /var/squid/lib/ssl_db/certs
/bin/mkdir -p /var/db/snort
/bin/mkdir -p /var/db/snort/iprep
/bin/mkdir -p /var/db/snort/sidmods
/bin/cp -Rp /root/sauv_db_clamav/* /var/db/clamav
/bin/cp -Rp /root/sauv_db_squidGuard/* /var/db/squidGuard/
/bin/chmod 1777 /var/tmp

in cron tab you have to add those lines

@reboot clamav /bin/sleep 80;/usr/pbi/squid-amd64/bin/freshclam --config-file=/usr/pbi/squid-amd64/etc/freshclam.conf;/bin/cp -Rp /var/db/clamav/* /root/sauv_db_clamav;/bin/pkill -9 squid;
@reboot root /bin/sleep 70;/root/;/bin/cp -Rp /var/db/squidGuard/* /root/sauv_db_squidGuard;/bin/pkill -9 squid
@reboot root /root/

Actions #1

Updated by Jim Thompson over 6 years ago

  • Assignee set to Jim Pingle
Actions #2

Updated by Jim Pingle over 6 years ago

  • % Done changed from 0 to 50

Fixed the snort directories in commit:ce8fedd

Will look into squidGuard soon.

Actions #3

Updated by Jim Pingle over 6 years ago

  • % Done changed from 50 to 70

Pushed a change for squid to teach clamav to keep its DB in a persistent location if /var is a RAM disk. It doesn't change often enough to warrant keeping it in a RAM disk, especially with limited space.

Actions #4

Updated by Jim Pingle over 6 years ago

  • Status changed from New to Feedback
  • % Done changed from 70 to 100

I pushed a change to teach squidGuard to keep its databases in a persistent directory when /var is in RAM. The files do not change frequently enough to warrant maintaining them in a RAM disk. Ticket #6878

Actions #5

Updated by Jim Pingle over 6 years ago

Each of these changes was made on 2.4 only, as some assumptions were made that could conflict in some cases (e.g. NanoBSD, which no longer exists on 2.4) and it was the best way to ensure the packages could be tested without causing issues on 2.3.x.

If someone wants to test the changes on 2.3.x and submit a pull request to bring variations of them in there, feel free.

The relevant commits are:

squid (clamav):
squidGuard (blacklists):

Actions #6

Updated by Jim Pingle over 6 years ago

  • Target version set to 2.4.0
  • Affected Version changed from 2.3.2 to All
  • Affected Architecture All added
  • Affected Architecture deleted ()
Actions #7

Updated by Jim Pingle over 6 years ago

  • Status changed from Feedback to Resolved

Seems to be working.

Actions #8

Updated by Kill Bill about 6 years ago

Jim Pingle wrote:

Seems to be working.

Yeah, this seems to be working, except that noone is getting the fixes. Considering that these are mainly for nanobsd users (which is entirely gone as a platform with 2.4), what's the point? (No, I don't know of any sane use case for the ramdisks on non-embedded with the way they work now, it is just a giant PITA breaking way more that it potentially fixes.)

Way too much branching going on here, plus generally the only advise possible is telling users to use the latest devel snapshot, not something people are keen to do in production.

Actions #9

Updated by Jim Pingle about 6 years ago

The thinking was: Without NanoBSD, more people will be running a full install on unreliable media like CF/SD, so we needed RAM disk behavior to be more reliable because more people would be using it.

There is no special purpose for those changes being held back, the main reason they didn't get merged is because I didn't test them on other versions and the changes were a bit large so I didn't want to copy them over without vetting them first. If the code works OK on 2.3.2/2.3.3 then it can be pulled back there.


Also available in: Atom PDF