Content filter default policy not applying to new zones

I’m sure this isn’t a big deal because by the time you get to this complex of a network, you would most likely want to have custom content filter profiles setup for your separate zones, but I added a second green zone:

…and the default profile did not apply to it. I got this error no matter where I browsed:

Until after I added this content filter profile:

Now everything works fine. Just thought I’d bring this to the devs’ attention. :smile:

1 Like

It seems that only the first green zone is automatically enabled to surf.
I’ll try to reproduce this in the coming days.

1 Like

No, I have two green zones, and I can surf from each zone without doing anything… With squid and web content filter activated…

1 Like

Well that’s odd… maybe I should test this on another VM in the morning and see if I see consistent results.

You got me thinking more about this and prompted some more immediate testing that I had not anticipated. :wink: I came up with the idea that maybe the cause was the order that I setup my NethServer instance. I setup my NS in the following order

  1. Add green and red zone
  2. Configure proxy and web filter
  3. Add 2nd green zone

I’d be willing to bet you setup yours in the following order:

  1. Add two green zones and red zone
  2. Configure proxy and web filter

So it looks like when a zone is added, a step is missing somewhere in NS to reconfigure the default web filter policy.

Please try to reproduce it on a fresh installation.

Please use this template!

Sorry about that @alefattorini. I should have collected more information and done more testing before posting this one.

Title updated to specify more detail.

I believe all of the other information from the template you posted is already in this thread. I’ll be sure and follow that in the future.

1 Like

Issue filed:


Another bug in QA, @Adam could you check it? /cc @dz00te

Verified this one too! :yum:


Great shot man! :wink:

Sorry to ask, can you please verify it again?

The fix was added to the wrong package.

That’s odd… Which package was it added to? Would the upgrade nethserver-base command I ran have installed the package that the fix was added to?

Edit: Oh… I see. It should have been the squid package, not base.


@giacomo, I don’t see the following package in the testing repo:

The latest one I see is 1.3.8-1.1 from Oct 8th.

I think the rpm is correctly published:

Try to clean yum cache:

yum --enablerepo=nethserver-testing clean
1 Like

I see what happened… The base update was in the 6.6 repo. I’ll install 6.7. Thanks!

Edit: I’m getting a conflict error when attempting to upgrade squid package. Am I doing something wrong?

sorry for the little OT
@giacomo I do not see folders
6.7 / testing
6.7 / nethforge-testing
in any of the mirror, including… it’s normal?

No you’re not, it’s a bug: It seems you’re a bug hunter! :smile:
I will fix it in few minutes…

1 Like

Yes, it’s normal.
Since the testing repository is transient, it’s not configured to be in sync across mirrors (CentOS does the same).
When a yum client request a package inside the testing repository, it will be always redirect to (see: This configuration allows all developers to have instant access to all rpms inside the testing repo.

Do you think is a good choice or we should add testing to the mirrors?

Again, it’s not you’re fault.
I didn’t realized that the bad nethserver-base rpm was wrongly published inside the 6.6 branch :frowning:

By the way, the 6.6 branch is now frozen and all fixes will be delivered for 6.7.
Thanks for you patience.

1 Like

That makes me feel better. :smile:

I’ll annoy everyone with notification emails by updating the issue in dev. :stuck_out_tongue_closed_eyes:

1 Like