Bug #6878
closed
how to use snort, squid and squid_guard with a ram disk
100%
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
Updated by
Updated by Jim Pingle about 8 years ago
- % Done changed from 0 to 50
Fixed the snort directories in commit:ce8fedd
Will look into squidGuard soon.
Updated by Jim Pingle about 8 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.
Updated by Jim Pingle about 8 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
Updated by Jim Pingle about 8 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:
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
Updated by Jim Pingle about 8 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 (
)
Updated by Jim Pingle almost 8 years ago
- Status changed from Feedback to Resolved
Seems to be working.
Updated by Kill Bill almost 8 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.
https://github.com/pfsense/FreeBSD-ports/pull/249#issuecomment-271535540
Updated by Jim Pingle almost 8 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.