Created attachment 5698 [details]
New squid.conf that works with squid-3.3.13-1.1.mga4

This squid.conf also works with bind-9.9.6.P1-1.mga4
acl mynetwork src 192.168.5.0/24
should evidently be modified for the case in question.

CC: (none) => bjarne.thomsen

I don't see the point between squid and bind

I am only telling how it happened. I cannot explain why it worked before the update of bind, but it did. I am not even sure when the change was introduced into squid.

The package is of course the famous drakx-net-text-2.12-1.mga4.
I found the broblem with squid in /var/log/squid/cache.log:
ERROR: No forward-proxy ports configured.

Source RPM: bind-9.9.6.P1-1.mga4 => drakx-net-text-2.12-1.mga4

drakgw should really edit the current recommended default of squid.conf.
I am going to investigate the minimum modification to squid.conf.default
when 5b2 is out.

Incidentally I found this warning after the error mentioned above:
WARNING: Forwarding loop detected for:
GET /subscribe?host_int=499653427&ns_map=22406897_301871798806257%2C23991039_3216954495743&user_id=14369475&nid=0&ts=1418385184 HTTP/1.1

This was before it stopped working.
It looks like a loop hole to me.

I cannot figure out where the squid.conf edited by drakgw comes from. It is not the squid.conf that comes with squid-3.3.13-1.1.mga4. I am unfortunably not a perl programmer.

could someone in mga5 do a default install (without network sharing), then do network sharing, and post the squid.conf and then fix the squid conf and then repost that one too??? so that i can see both the one created by network sharing (that is supposed to be wrong) and the one that works?

CC: (none) => alien

looking at the code, it seems like the only thing network sharing does with squid is use the lan interface and set the network/prefix from the interface into the squid.conf?

i will need the exact settings used in network sharing and network configuration.

what is the lan interface, what are it's settings wrt ip, network and netmask.


following a fresh install, what are exactly the steps you use?
eg:

1. configure internet during install(?)
2. configure lan (?)
3. internet sharing (?)

are those the steps? or are you doing internet sharing directly? did you choose the wrong interface, etc...

and, what are the options you use.

it's important that we do this in a clean installed mga5 setup, so that we're sure...

Yes, I agree. But it would have to wait until m5b2 is out, unless somebody else has a cleen mga5 setup with the right hardware. My hardware is a slow fitpc2 with 2 ethernet ports that only works well with the MATE desktop. I hesitate to install m5b1 followed by all the many updates.

well, i can try to take a peek into this, but i need this data... and i don't have a lot of time to spend, so if this is wanting to be fixed before release... there's not much time...-

Well, I have a cauldron version running in virtualbox without a gw configured, and squid is not installed. When I install squid, the squid.conf looks very much like my attachment above, apart from the modifications that I mentioned. In mga4 a reconfiguration overwrote my modified version with a very old version. I have no idea where it comes from. I can try to install m5b1 followed by an update to the current cauldron. The steps used wil be
1. configuring eth0 for the internet
2. configuring eth1 for internet sharing
3. running private firewall to make sure that only eth0 and wlan are protected
I shall write down the fixed IP-number and netmask for eth0.
Internet sharing will install squid and overwrite squid.conf.
Should I install squid manually before the internet sharing, so that I can save a copy of squid.conf, before it is modified?

This may take some time. My fitpc2 has this stupid poulsbo graphics chip that used to give a lot of difficulties during installation.

Let me explain my actual configuration in mga4 befor I install mga5.
The situation is as follows:
Tilgin fiber router:
LAN  IP: 192.168.1.1
Netmask: 255.255.255.0
Tilgin port forwarding of ssh and Web to IP: 192.168.1.100
                                    Netmask: 255.255.255.0
windbox (mga4) net configuration of eth0 IP: 192.168.1.100
                                    Netmask: 255.255.255.0
windbox local configuration of eth1      IP: 192.168.5.1
                                    Netmask: 255.255.255.0
dhcpd.conf is configured to give all machines fixed IP-adresses

fitpc2 (mga4) net configuration of eth0  IP: 192.168.5.116
                                    Netmask: 255.255.255.0
fitpc2 local configuration of eth1       IP: 192.168.15.1
                                    Netmask: 255.255.255.0
"Share the Internet connection" writes
Warning! An existing firewalling configuration has been detected.
You may need some manual fixes after installation.

"Manage system services by enabling or disabling them" shows
that Shorewall and Squid have stopped, and both refuse to start.

I now copy my version of squid.conf onto the modified one.
I can now start squid, but shorewall still refuses to start.

I next use
mcc-> Set up your personal firewall
where I unselect eth1

After that shorewall is running.

Now the sub-net 192.168.15.0 works.

drakgw has internally an specific squid.conf file, if there's something better or different about the normal one, please tell me, i can modify some things if it's a better default...

tbh, i think the steps should be:

1) configure internet (during install)
2) configure internet sharing on the lan

those steps alone should really give a working setup...

OK. The problem is that both shorewall and squid have been changed in order to tighten security. There are 2 problems

a) As I wrote in Bug 12883:
I am now ready to share the interne by running drakgw.
cat /etc/shorewall/interfaces
#ZONE           INTERFACE               OPTIONS
net     eth0    detect
net     eth1    detect
net     wlan0   detect
loc     eth1    detect
Note, eth1 is now in both zone net and zone loc.
I am not sure how, but it can be fixed by drakfirewall.

b) The internal squid.conf file is far too old (> 10 years?)
   The current squid.conf.default is quite different, and no
   ports are mentioned.

Unfortunately, I do not know anything about squid.
But I could do some experiments by adding a minimum
number of extra lines in order to make it work.
I am not sure how many lines drakgw puts into the internal
squid.conf. Does it enter port numbers?

I am going to install m5b1 on fitpc2.

Maybe you could attach the internal squid.conf, so I could compare it with the current squid.conf.default?

you can see it here: http://gitweb.mageia.org/software/drakx-net/tree/lib/network/squid.pm#n23 (sort of)

Further discussions of this problem is moved to Bug 14904 for mga5

ok, i submitted drakx-net-2.14-1.mga4 to update_testing...

plz test and validate it

Please give advisory and rpms too as per updates policy. Thanks.

In my opinion it is of great value to be able to compare the same changes to drakx-net in both mga4 and mga5.

After a reboot in mga5 shorewall was not started, after a "Sharing of the internet". The situation is different in mga4.

After "Sharing the internet" all relevant services seems to be running.
However, a "systemctl status dhcpd" gives this error message:
dhcpd[16435]: receive_packet failed on eth1: Network is down
This is however fixed by restarting dhcpd:
systemctl restart dhcpd

The situation is slightly different after a subsequent reboot.
All relevant services are running except dhcpd.
The reason is according to "systemctl status dhcpd":
dhcpd[1681]: Not configured to listen on any interfaces!

This is again fixed by restarting dhcpd.
Now my gateway to the outside world works again.

what's in /etc/sysconfig/dhcpd ?

or /etc/dhcpd/dhcpd.conf ?

does drakgw also generate dhcpd.conf? 

i assume this is only mga4?

for shorewall nog being started in mga5. since the service is enabled, it will have started, you'll have to check the journal to see why it didn't take...

this can be tested by running drakgw and enabling squid options, check for shorewall and squid to be working after running it and check shorewall interfaces to see if no interface is both in loc and net zone.

to successfully test it, you will need 2 network interfaces (LAN and internet)

luckily, it can be tested in a virtual machine.

Suggested advisory:
========================

Updated drakx-net to fix handling of squid and shorewall configuration when running drakgw

This update also has updated translations

========================

Updated packages in core/updates_testing:
========================
drakx-net-2.14-1.mga4

Source RPMs: 
drakx-net-2.14-1.mga4.src.rpm

I have now testet drakgw on another PC running mga4 after updating to
drakx-net-2.14-1.mga4. This box has an ethernet and a WiFi connection.
The WiFi interface wlp3s0 is chosen as the internet connection.
After running drakgw I have
cat /etc/shorewall/interfaces
net     wlp3s0  detect
loc     enp2s0  detect

All the services (squid, shorewall, named, iptables) are running,
again except dhcps, which has to be started with
systemctl start dhcpd

After that I can connect a laptop to the subnet (192.168.10.0)
using the ethernet connection.
So, the only problem is that dhcpd has to be started manually.

but, it shouldn't...

can you show the following:

systemctl status dhcpd.service  (after a boot, before start)

and look at:

journalctl -a -l -b -u dhcpd.service

see if it was started but failed for some reason.

if it's not enabled in the status, try:

systemctl enable dhcpd.service (but let us know, ok!)

In the meantime I have made a fresh mga5b1 install on the same PC, followed by an update to current cauldron. The advantage is that the graphics works in both mga4 and mga5.
Exactly the same thing happened in mga5. dhcpd was inactive after running drakgw, but it was running after a re-boot.
I will now try a reconfiguration of the local net.
systemctl status dhcpd.service:
â dhcpd.service - DHCPv4 Server Daemon
   Loaded: loaded (/usr/lib/systemd/system/dhcpd.service; enabled)
   Active: active (running) since Thu 2015-01-01 19:35:11 CET; 5min ago
  Process: 27441 ExecStart=/usr/sbin/dhcpd -pf /run/dhcpd/dhcpd.pid -cf $CONFIGFILE -lf $LEASEFILE $OPTIONS $INTERFACES (code=exited, status=0/SUCCESS)
 Main PID: 27442 (dhcpd)
   CGroup: /system.slice/dhcpd.service
           ââ27442 /usr/sbin/dhcpd -pf /run/dhcpd/dhcpd.pid -cf /etc/dhcpd.conf -lf /var/lib/dhcpd/dhcpd.leases -q enp2s0

Jan 01 19:35:11 localhost.localdomain dhcpd[27441]: Not searching LDAP since ldap-server, ldap-port and ldap-base-dn were not specified in the config file
Jan 01 19:35:11 localhost.localdomain dhcpd[27441]: Wrote 1 leases to leases file.
Jan 01 19:35:11 localhost.localdomain dhcpd[27442]: Server starting service.
Jan 01 19:35:17 localhost.localdomain dhcpd[27442]: receive_packet failed on enp2s0: Network is down

In mga4 I got
dhcpd[16435]: receive_packet failed on eth1: Network is down

On mga5 I also noticed that mandi was not running.

On both mga4 and mga5 right after LAN reconfiguration "stat dhcpd" gives this error: receive_packet failed: Network is down.

After a reboot the situation is different:
In mga4 systemctl stat dhcpd.service:
dhcpd.service - DHCPv4 Server Daemon
   Loaded: loaded (/usr/lib/systemd/system/dhcpd.service; enabled)
   Active: failed (Result: exit-code) since Thu 2015-01-01 21:41:47 CET; 4min 59s ago
  Process: 1646 ExecStart=/usr/sbin/dhcpd -pf /run/dhcpd/dhcpd.pid -cf $CONFIGFILE -lf $LEASEFILE $OPTIONS $INTERFACES (code=exited, status=1/FAILURE)

Jan 01 21:41:47 windbox.astronomy dhcpd[1646]:
Jan 01 21:41:47 windbox.astronomy dhcpd[1646]: Not configured to listen on any interfaces!
Jan 01 21:41:47 windbox.astronomy dhcpd[1646]:
Jan 01 21:41:47 windbox.astronomy dhcpd[1646]: If you did not get this software from ftp.isc.org, please
Jan 01 21:41:47 windbox.astronomy dhcpd[1646]: get the latest from ftp.isc.org and install that before
Jan 01 21:41:47 windbox.astronomy dhcpd[1646]: requesting help.
Jan 01 21:41:47 windbox.astronomy dhcpd[1646]:
Jan 01 21:41:47 windbox.astronomy systemd[1]: dhcpd.service: control process exited, code=exited status=1
Jan 01 21:41:47 windbox.astronomy systemd[1]: Failed to start DHCPv4 Server Daemon.
Jan 01 21:41:47 windbox.astronomy systemd[1]: Unit dhcpd.service entered failed state.

In mga5 dhcpd runs just fine, but mandi is dead
whereas mandi is running just fine in mga4.

Why does is claim that "Not configured to listen on any interfaces!" in mga4.
systemctl start dhcpd.service
starts dhcpd without any errors!

could you give the contents of /etc/sysconfig/dhcpd for both? that's where the interfaces should be configured.

also the /etc/dhcpd.conf file plz...

so, if i understand correctly, when you execute drakgw (it configures the lan, but the lan is down? at the point where dhcpd is started...?)

i'll check the order that drakgw does.

maybe it's started on install? and not restarted after reconfigure drakgw?

maybe harddrake2 removes the interface for some reason at the reboot in /etc/sysconfig/dhcpd ...

i thing i need more on dhcpd before the last 10 lines... could you do on windbox:

journalctl -a -l -u dhcpd.service --since="2015-01-01 21:41:46"

ok, i figured out what happened...

the dhcpd gets started before the interface goes up...

the real solution is to on interface up restart/reload any configured dhcpd.service for configured interfaces.

i would advise you to make a new bug for that. and put coling in CC

(mandi might be a similar issue, but i don't know anything about that, or even if that is useful at all...)

Is this update candidate ready for testing, or is more work needed?

IIRC, comment 24 confirms that the update candidate is working, but there is another bug that might be worth discussing in another BR?

CC: (none) => remi

s/IIRC/IIUC/

This bug is fixed!

Resolution: (none) => FIXED
Status: NEW => RESOLVED

We still need to test and validate the update for Mageia 4 Bjarne :)

Did you test it on Mageia 4, and if so on which architecture?

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

Yes. I have created subnets in both mga5 and mga4, and I can access http
from both subnets.
The other problems with the start-up of dhcpd and/or mandi during booting
are unrelated.

Thanks :) Which architecture(s) did you test? We usually try to test both archs on every supported release, so if you tested one of them (or both) it will help speed up the process.

I have tested mga4 and mga5 in i586, only. The mga4 box is my gw to the outside
world. Maybe somebody else could test mga4 and mga5 in x86_64?

Perfect, I add the corresponding tag for the QA team then. Someone else with x86_64 hardware will hopefully test the update soon too.

Whiteboard: (none) => MGA4-32-OK

If it has been verified that the bug is fixed, it's probably not really necessary to do a full duplicate test on the other arch (the affected code isn't arch dependent anyway), so as long as it installs fine, we should be good to go now that we've got confirmation that the bug fix was successful.

This is noarch and the issues are confirmed fixed by the reporter. No regressions noticed and difficult for QA to verify without appropriate equipment.


Validating. Advisory uploaded.

Please push to 4 updates

Thanks

An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGAA-2015-0011.html

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED