Fixing up the Squid3+Squidguard install fun

jimp

So I have an idea about the current packaging of Squid+Squidguard but I'm not quite sure if it's the best thing do to. Given that there is a bit of a mess now where you have to do some crazy dance of installing squid, then squidguard, then squid3, etc, to make things work is obviously not workable long-term, neither is completely switching over Squidguard to only squid3. So I was thinking of doing one of two things for 2.1 only (2.0.x wouldn't get this):

Option 1:
We can make a Separate "SquidGuard for Squid3" and "Lightsquid for Squid3" and "Sarg for Squid3" package, and in their build configuration, they can specify squid3 to be built before they get built, and specify a custom name so their PBIs don't conflict.

Pros: Easier to fit into the current package lineup/scheme.
Cons: ?

Option 2:
We can work on some bundled packages such as "Squid3+SquidGuard" that actually has them both in the same PBI and would have one main XML file that downloads the actual components from "real" squid and squidguard packages rather than a completely separate/redundant copy.

Pros: Installs everything at once, no need to juggle multiple packages.
Cons: More difficult to maintain on the backend, would still require some custom coding/redundancy in the combined package XML.

I like the idea of option 2 better, but it's a bit more work and I'm not sure it's worth it.

Any thoughts?

romainp

I like very much the Option 1. By this way there is no confusion about what the user will be installing on which version of PfSense. And if a link to the official doc on thr web site could be added to the package description, the user could go ther eand read why there is a different version and some check and fix howtos.

Romain

maverick_slo

Hi!

Option 1 for sure!

Regards,
Greg

Tikimotel

Option 1 has my vote.

Option 2 only viable for certain use cases.
Unless you know how many installs actively use the combination of the two packages at once.
If that is more than 99% of all users then this package combination might be worthwhile to be served as a single package.

traxxus

+1 for Option 1

jimp

Well I've tried a half dozen different ways to get squidGuard to build itself against Squid 3.3 but for some reason it just refuses to cooperate. No matter what I set, it's assuming Squid 2.x. I'll have to poke at it some more as time allows.

It doesn't look like Sarg or Lightsquid have any specific dependency on squid so those won't need to be handled, it's just SquidGuard that needs special treatment it appears.

ariyako

Option 2! ;D

stephenw10

Is there any disadvantage to installing Squidguard and then not enabling it for those who want Squid only? More difficult to maintain as already mentioned. It would be very interesting to know how many people use Squid without Squidguard. A poll perhaps? As I read the first post here I assumed everyone would vote option 2, shows how much I know. ::)

Steve

jimp

@stephenw10:

Is there any disadvantage to installing Squidguard and then not enabling it for those who want Squid only? More difficult to maintain as already mentioned. It would be very interesting to know how many people use Squid without Squidguard. A poll perhaps? As I read the first post here I assumed everyone would vote option 2, shows how much I know. ::)

Wasted space, mostly. Also I'm not sure if there may be some compatibility issues with having that and Dansguardian and who knows what else installed. It's best to keep things simple when possible.

I think the "combined" packages are probably not going to be realistically feasible, I'm still trying to move forward with Option #1 above.

Tikimotel

I don't know how interwoven squid is in the squidguard package itself.
All I need to change to get it to work "proper" with squid v3.3 is change a few lines in the "squidguard_configurator.inc".
And re-save the options in the GUI.

Certain options are rename/changed from squid v2 to squid v3.1 and onwards. (mainly the redirectors)

After a firmware update, and the re-install of all packages is complete is change "squidguard_configurator.inc".

# ------------------------------------------------------------------------------
# squid config options
# ------------------------------------------------------------------------------
define('REDIRECTOR_OPTIONS_REM',   '# squidGuard options');
define('REDIRECTOR_PROGRAM_OPT',   'url_rewrite_program');
define('REDIRECT_BYPASS_OPT',      'url_rewrite_bypass');
define('REDIRECT_CHILDREN_OPT',    'url_rewrite_children');
define('REDIRECTOR_PROCESS_COUNT', '12 startup=8 idle=6 concurrency=0'); # redirector processes count will started

(number of redirectors/rewrite_children maxes out at 12, starts with 8 and idles at 6 and is an older type of redirector)

Basically the configurator script needs change (or version detection), why it needs squid33 or squid2 for compilation is beyond me.
Is it only needed for ease of installation? Why was squid2 integrated into the package install process?

jimp

I found/fixed a bug in the pbi build scripts (not our script, the one from upstream) and got some binaries built late on Friday finally. I need to poke at them a little before I activate them, but they may be up yet today.

jimp

The "squidguard-squid3" package should appear shortly. For those interested in trying it out, remove squid 2.x, squid 3.x, and squidguard to get back to a "clean" state, then install squid 3.x and squidguard-squid3.

In the future, if this works, installing squid 3.x and squidguard-squid3 should be the only steps needed.

technical

option 1 8)