Topic: Squidguard config

[daz69]

I've been playing with SME server and squidguard using J Bennett 's package and have successfully got it working ok.

Although the 'content filtering' integrates into the web based admin, it only gives you the ability to allow or disallow either users/ips or domains/URLs/Expressions not to create groups etc to enable different levels of access. I know I can achieve what I need from manually editing the squidguard.conf, but a note inside the file states that when the file is regenerated all changes will be lost.

With my limited understanding of SME I know that the standard template is expanded from the e-smith original, but when does that happen? - I can see it happening in the supdate script after a blacklist update, but again, when does that run?

So I guess I'm asking how do you configure more options than the web interface allows without losing your changes by being overwritten a template?

Thanks -- Darren

[Stefano]

Hi Darren, welcome here

to understand how SME's templating system works, please read this wiki page

HTH

[daz69]

Thanks for the reply, after intensive study I can see the idea behind it but am I right in saying that if I only want to manually administer squidguard.conf (not through server manager) I can just create my file in templates-custom and because its a file not a directory it will be used instead of the expanded template?

[mrjhb3]

You can always give an example of how a group ACL would work and I can see if I can incorporate that into the RPM.      I've never looked at groups, but could see it as a useful feature.


You should be able to use templates-custom to override any settings you want.  I don't remember how many template fragments there are, but you would need to make sure you add the same fragment names.  If you don't want the info in those fragmentseven if they are just blank, so that your customizations will be used.


Lastly, my caveat.  I updated this package for my own use.  I use this package at home to monitor my kids' access.  It's not put in smecontribs as there is more work that needs to be done, IMO, before it should move there which is why it's in my contribs dir.  If people want it moved to smecontribs, I can certainly do that. 


Also note that this package will not work on SME 8 as some of the directives need to change.  I hope to get to that sometime in the future after sme 8 is released and I find the need to upgrade and need this feature.


John Bennett

[janet]

daz69

sme server uses the config files in /etc/xxxxxx just like any other Linux. In sme we do not edit the /etc/xxxx config files directly (as you would do in a regular Linux).

Changes are made by server manager, additional command line db settings, or by customising the code that generates the config settings. This code is in the templates. Templates are composed of fragments. These are not regular config files, they are the code that generates part (ie a fragment) of the config files.

The /etc/xxxx config files are created from the code in the template fragments & default values in the main template fragments in /etc/e-smith/templates/xxxx/yyyy
The code in the template fragments also look up values in the various databases in /home/e-smith/db/xxxxxxx (where the code has been written to support db settings).
In addition there are custom template fragments in the /etc/e-smith/templates-custom/xxxx/yyyy folder structure.  The code in these custom template fragments add configuration settings in addition to the settings generated by the main template fragments, or where the custom template fragments are identically named, they completely replace the settings generated by the main template fragments.

The config files are generated when you expand the templates using
expand-template /etc/xxxx/yyyy
You also need to restart affected services eg using
sv t /service/xxxxxservicename
Some signal events combine template expansion and service restart eg
signal-event email-update
or one of the many other signal events as appropriate for the task ypou are doing.
If in doubt which template to expand and service to restart, there is a "master" command that will expand all templates and restart all services, in effect reapplying all configuration settings, and it is safe to do anytime using
signal-event post-upgrade
signal-event reboot

To make a custom template change, copy the existing fragment of interest from the /etc/e-smith/templates/xxx/yyy tree to the corresponding /etc/e-smith/templates-custom/xxxx/yyyy tree, edit the copied fragment with required changes, then expand & restart as above.
You can also create new custom template fragments when an existing one does not exist that is suitable for the job. You need to name this in a correct numerical order, so the changes you want to make will be placed in the correct location in the /etc/xxxx config file.

Why do all this by design ?
To have robust default system settings that can easily be reverted to just by deleting the custom template fragments & expanding & restarting. The system will then return to correct functional settings.
That is why the main templates should never be modified, so all default template code remains unaltered and intact.

You will need to locate the template fragment of interest and read the code to decide which fragment you want to copy and make changes to. You can usually deduce this from the specific /etc/xxxx config file that you are trying to make changes to ie one correlates to the other.

I strongly suggest you review many of the Howtos and Contrib wiki articles that have these types of configuration changes described, as it will give you step by step examples which you can then apply to your particular needs (changing the service and fragment names & the expansion config names of course). Also search these forums on expand-template for numerous examples.