1 Topic by mir (edited by mir 2015-06-16 05:15:03)

  • mir
  • Member
  • Offline
  • Registered: 2014-05-30
  • Posts: 170

Topic: Bug in iptables script

==== Required information ====
- iRedMail version: 0.9.2
- Store mail accounts in which backend (LDAP/MySQL/PGSQL): LDAP
- Web server (Apache or Nginx): Apache
- Linux/BSD distribution name and version: Debian 8
- Related log if you're reporting an issue:
====
To be able to start/stop iptables on Debian 8 without systemd throwing an error the following script needs to be created in /etc/default named iptables-config with the following content:
IPTABLES_MODULES_UNLOAD=no

The reason is that the function rmmod_r() in /etc/init.d/iptables seems to be incapable of unloading the iptables modules in which case it trows an error code making systemd complain of a failing script.

Not having the file with the content doesn't mean iptables will not be loaded with the rules in /etc/default/iptables but to avoid a lot of noise in the logs and when starting and stopping the server you should apply the file anyway

----

Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.

2 Reply by SteveLuxe

  • SteveLuxe
  • Member
  • Offline
  • Registered: 2015-06-02
  • Posts: 115

Re: Bug in iptables script

mir wrote:

To be able to start/stop iptables on Debian 8 without systemd throwing an error the following script needs to be created in /etc/default named iptables-config with the following content:
IPTABLES_MODULES_UNLOAD=no

The reason is that the function rmmod_r() in /etc/init.d/iptables seems to be incapable of unloading the iptables modules in which case it trows an error code making systemd complain of a failing script.

That's really strange, mir, because I'm also running Debian 8, with iRedMail 0.9.2, and I didn't have to do anything anywhere near that... Mine just worked out of the box, so to speak. Given, I did a clean install of Debian 8, not upgraded from 7, and a fresh install of iRedMail 0.9.1, later upgraded to 0.9.2.

I could be completely wrong, but I didn't think that /etc/init.d/ really had much to do with anything except for legacy apps that only have Sys-V init scripts bundled with them. Since Debian 8 moved to systemd, there really shouldn't be much going on with /etc/init.d/ except for backward compatibility.

Did you upgrade from Wheezy? I'm just wondering purely out of curiosity. Perhaps a bug in the upgrade process? On my system, I can do a "service iptables stop / start / restart" and it just works... Are you still calling /etc/init.d/iptables, or are you using "service iptables", or perhaps "systemctl start iptables.service"?

3 Reply by mir

  • mir
  • Member
  • Offline
  • Registered: 2014-05-30
  • Posts: 170

Re: Bug in iptables script

Do you have this file: /etc/default/iptables-config ?

It has nothing to do with either sysV or systemd there is a bug in the script. Apart from this scripts in /etc/init.d are used by systemd as well but on systemd enabled systems these scripts will be run through systemd instead of being run directly by bash.

My installation is originally installed when iredmail was 0.7.x on Debian Wheezy and has been upgraded as iredmail has released new releases. This also means an upgrade from wheezy to jessie which did require some small manual changes in iredmail of which it seems not all corner cases has been resolved. A clean install of 0.9.1 on a fresh jessie presumably does not trigger legacy behavior.

4 Reply by SteveLuxe

  • SteveLuxe
  • Member
  • Offline
  • Registered: 2015-06-02
  • Posts: 115

Re: Bug in iptables script

mir wrote:

Do you have this file: /etc/default/iptables-config ?

No... I checked. It's nowhere on my system. Sounds like maybe there's a configuration difference between an upgraded Jessie, and a freshly installed Jessie.

5 Reply by mir

  • mir
  • Member
  • Offline
  • Registered: 2014-05-30
  • Posts: 170

Re: Bug in iptables script

SteveLuxe wrote:

No... I checked. It's nowhere on my system. Sounds like maybe there's a configuration difference between an upgraded Jessie, and a freshly installed Jessie.

I think so too. But, as said, only in corner cases.

6 Reply by ZhangHuangbin

  • ZhangHuangbin
  • ZhangHuangbin
  • iRedMail Developers
  • Offline
  • Registered: 2009-05-06
  • Posts: 30,770

Re: Bug in iptables script

Hi mir,

Did you try to copy file 'samples/iptables.init.debian' to your Debian 8 server? does it work?

7 Reply by mir

  • mir
  • Member
  • Offline
  • Registered: 2014-05-30
  • Posts: 170

Re: Bug in iptables script

ZhangHuangbin wrote:

Hi mir,

Did you try to copy file 'samples/iptables.init.debian' to your Debian 8 server? does it work?

No, I was not aware of its presence. Is this file not installed by iredmail installer? If it is I would suggest that the upgrade script notified users when scripts installed by the installer is changed/updated in a newer release.

8 Reply by ZhangHuangbin

  • ZhangHuangbin
  • ZhangHuangbin
  • iRedMail Developers
  • Offline
  • Registered: 2009-05-06
  • Posts: 30,770

Re: Bug in iptables script

This file will be installed at initial iRedMail installation, but not mentioned in upgrade tutorials when we improved it or fixed issue.
This is the first report.

9 Reply by mir

  • mir
  • Member
  • Offline
  • Registered: 2014-05-30
  • Posts: 170

Re: Bug in iptables script

ZhangHuangbin wrote:

This file will be installed at initial iRedMail installation, but not mentioned in upgrade tutorials when we improved it or fixed issue.
This is the first report.

My I suggest to mention this in the upgrade tutorial. A quick way to automatically detect changes is to compare a hash between the installed script and the new one.

10 Reply by mir

  • mir
  • Member
  • Offline
  • Registered: 2014-05-30
  • Posts: 170

Re: Bug in iptables script

ZhangHuangbin wrote:

Hi mir,

Did you try to copy file 'samples/iptables.init.debian' to your Debian 8 server? does it work?

I have installed the script from 0.9.1 (did not have 0.9.2 local). It seems to have fixed the issue and the fix in this new script does exactly what I found out proofing my fix was correct;-):

Default setting in new script:
IPTABLES_MODULES_UNLOAD="no"

Default setting in old script:
IPTABLES_MODULES_UNLOAD="yes"