how to use snort, squid and squid_guard with a ram disk
create 2 directories in /root
you need to create a file named creation_des_repertoire_squid_et_snort_dans_var.sh in /root/ with those commands in it
/usr/sbin/chown squid:proxy /var/squid/acl
/usr/sbin/chown proxy:proxy /var/squid/lib
/usr/sbin/chown squid:proxy /var/squid/logs
/usr/sbin/chown squid:proxy /var/squid/lib/ssl_db
/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
#4 Updated by Jim Pingle 3 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 3 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:
squid (clamav): https://github.com/pfsense/FreeBSD-ports/commit/38872566f0001d804f33c3985ca28b199c49049c
squidGuard (blacklists): https://github.com/pfsense/FreeBSD-ports/commit/033c76879853ac2c4ddb2c0078213c7ce830f679
#8 Updated by Kill Bill about 1 month 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.
#9 Updated by Jim Pingle about 1 month 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.