Content filter default policy not applying to new zones


(Adam) #1

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:


(Filippo Carletti) #2

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


#3

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


(Adam) #4

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.


(Alessio Fattorini) #5

Please try to reproduce it on a fresh installation.


Please use this template!


(Adam) #6

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.


(Filippo Carletti) #7

Issue filed:
http://dev.nethserver.org/issues/3275


(Alessio Fattorini) #8

Another bug in QA, @Adam could you check it? /cc @dz00te
http://dev.nethserver.org/issues/3275


(Adam) #9

Verified this one too! :yum:


(Alessio Fattorini) #10

Great shot man! :wink:


(Giacomo Sanchietti) #11

Sorry to ask, can you please verify it again? http://dev.nethserver.org/issues/3275

The fix was added to the wrong package.


(Adam) #12

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.


(Adam) #13

@giacomo, I don’t see the following package in the testing repo:
nethserver-squid-1.3.8-1.2.g014d519.ns6.noarch.rpm

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


(Giacomo Sanchietti) #14

I think the rpm is correctly published: http://packages.nethserver.org/nethserver/6.7/testing/x86_64/Packages/nethserver-squid-1.3.8-1.2.g014d519.ns6.noarch.rpm

Try to clean yum cache:

yum --enablerepo=nethserver-testing clean

(Adam) #15

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?


#16

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


(Giacomo Sanchietti) #17

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


(Giacomo Sanchietti) #18

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 packages.nethserver.org (see: https://github.com/NethServer/mirrorlist/blob/master/6.7/nethserver.php#L27). 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?


(Giacomo Sanchietti) #19

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.


(Adam) #20

That makes me feel better. :smile:

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