Project

General

Profile

Bug #6878

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

Added by sylvain sylvain 9 months ago. Updated 6 months ago.

Status:
Resolved
Priority:
Very Low
Assignee:
Category:
-
Target version:
Start date:
10/27/2016
Due date:
% Done:

100%

Affected version:
All
Affected Architecture:
All

Description

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

you need to create a file named creation_des_repertoire_squid_et_snort_dans_var.sh 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/squidGuard_blacklist_update.sh;/bin/cp -Rp /var/db/squidGuard/* /root/sauv_db_squidGuard;/bin/pkill -9 squid
@reboot root /root/creation_des_repertoire_squid_et_snort_dans_var.sh

History

#1 Updated by Jim Thompson 9 months ago

  • Assignee set to Jim Pingle

#2 Updated by Jim Pingle 8 months ago

  • % Done changed from 0 to 50

Fixed the snort directories in commit:ce8fedd

Will look into squidGuard soon.

#3 Updated by Jim Pingle 8 months 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.

#4 Updated by Jim Pingle 8 months 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

#5 Updated by Jim Pingle 8 months 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:

snort: https://github.com/pfsense/FreeBSD-ports/commit/ce8feddcd1d675ebaa6062fe82dc7267ed771d49
squid (clamav): https://github.com/pfsense/FreeBSD-ports/commit/38872566f0001d804f33c3985ca28b199c49049c
squidGuard (blacklists): https://github.com/pfsense/FreeBSD-ports/commit/033c76879853ac2c4ddb2c0078213c7ce830f679

#6 Updated by Jim Pingle 8 months ago

  • Target version set to 2.4.0
  • Affected version changed from 2.3.2 to All
  • Affected Architecture set to All

#7 Updated by Jim Pingle 8 months ago

  • Status changed from Feedback to Resolved

Seems to be working.

#8 Updated by Kill Bill 6 months 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.
https://github.com/pfsense/FreeBSD-ports/pull/249#issuecomment-271535540

#9 Updated by Jim Pingle 6 months 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