Bug#804648: nftables: Can not start service with systemctl
wanglihe
Version: 0.5-1~bpo8+1
Severity: normal
Dear Maintainer,
When I ran command "systemctl enable nftables", it gave wrong message:
Synchronizing state for nftables.service with sysvinit using
update-rc.d...
Executing /usr/sbin/update-rc.d nftables defaults
Executing /usr/sbin/update-rc.d nftables enable
update-rc.d: error: nftables Default-Start contains no runlevels,
aborting.
It seems that you put run level after Default-stop, but it should put
after Default-start, in the file /etc/init.d/nftables.
When this bug fixed, maybe you should give tips about firewall rules, or
just leave "flush ruleset" in /etc/nftables.conf, I think everything
should not change after installation, not "connect refuse".
The new nftables.conf need add one more line code about include files under
/etc/nftables/ .
-- System Information:
Debian Release: 8.1
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages nftables depends on:
ii init-system-helpers 1.22
ii libc6 2.19-18
ii libgmp10 2:6.0.0+dfsg-6
ii libmnl0 1.0.3-5
ii libnftnl4 1.0.5-1~bpo8+1
ii libreadline6 6.3-8+b3
nftables recommends no packages.
nftables suggests no packages.
-- no debconf information
Arturo Borrero Gonzalez
> Package: nftables
> Version: 0.5-1~bpo8+1
> Severity: normal
>
> Dear Maintainer,
>
> When I ran command "systemctl enable nftables", it gave wrong message:
>
> Synchronizing state for nftables.service with sysvinit using
> update-rc.d...
> Executing /usr/sbin/update-rc.d nftables defaults
> Executing /usr/sbin/update-rc.d nftables enable
> update-rc.d: error: nftables Default-Start contains no runlevels,
> aborting.
>
> It seems that you put run level after Default-stop, but it should put
> after Default-start, in the file /etc/init.d/nftables.
Please note that despite of these messages,
* 'systemctl enable nftables' does enable the service
* 'systemctl disable nftables' does disable the service
(you may check with 'systemctl status nftables')
The error messages is because the sysvinit-systemd compat stuff, which
tries to sync systemd/sysvinit services so you may change between init
systems smoothly.
The sysvinit init script is shipped absolutely disabled, you have to
manually edit the file to use it.
>
> When this bug fixed, maybe you should give tips about firewall rules, or
> just leave "flush ruleset" in /etc/nftables.conf, I think everything
> should not change after installation, not "connect refuse".
>
> The new nftables.conf need add one more line code about include files under
> /etc/nftables/ .
>
Are you complaining about the shipped /etc/nftables.conf file?
I fail to understand what is wrong here.
thanks, best regards
--
Arturo Borrero González
Lihe Wang
1: I do not agree about "despite message". Everything should not give wrong message, if run correct. As a programmer, when I write script, how can I do about wrong message? some of them is really wrong, and others means nothing?
2: Yes, the shipped config file, drop almost everything. I can not login remote server, no ping response, just because I install nftables. It is bad. The things goes wrong way, even if it wants more security. everything should leave unchanged, and then, I add rules.
Arturo Borrero Gonzalez
> 1: I do not agree about "despite message". Everything should not give wrong
> message, if run correct. As a programmer, when I write script, how can I do
> about wrong message? some of them is really wrong, and others means nothing?
>
yeah, perhaps it makes sense. I just don't want to support 2 init systems.
> 2: Yes, the shipped config file, drop almost everything. I can not login
> remote server, no ping response, just because I install nftables. It is
> bad. The things goes wrong way, even if it wants more security. everything
> should leave unchanged, and then, I add rules.
[...]
# activate the following line to accept common local services
#tcp dport { 22, 80, 443 } ct state new accept
[...]
So, you just need to uncomment that line to start accepting incoming
SSH/Web connections.
The shipped configuration is a secure one: a white-list type firewall,
which drop all connections unless stated otherwise. It's intended for
a simple workstation.
You should not enable the firewall without reading the ruleset first.
That's why the user has to manually enable the nftables systemd service.
Regarding the /etc/nftables directory: it should not be there, and the
next package upload to debian will not carry the directory.
--
Arturo Borrero González
Lihe Wang
2015年11月12日 上午2:54于 "Arturo Borrero Gonzalez" <arturo.bo...@gmail.com>写道：
>
> On 11 November 2015 at 03:50, Lihe Wang <wanglihe....@gmail.com> wrote:
> > 1: I do not agree about "despite message". Everything should not give wrong
> > message, if run correct. As a programmer, when I write script, how can I do
> > about wrong message? some of them is really wrong, and others means nothing?
> >
>
> I could drop the /etc/init.d/nftables file ...
> yeah, perhaps it makes sense. I just don't want to support 2 init systems.
>
yes, forget init, I like systemd too.
> > 2: Yes, the shipped config file, drop almost everything. I can not login
> > remote server, no ping response, just because I install nftables. It is
> > bad. The things goes wrong way, even if it wants more security. everything
> > should leave unchanged, and then, I add rules.
>
> Right now, the file /etc/nftables.conf includes this:
>
> [...]
> # activate the following line to accept common local services
> #tcp dport { 22, 80, 443 } ct state new accept
> [...]
>
> So, you just need to uncomment that line to start accepting incoming
> SSH/Web connections.
>
> The shipped configuration is a secure one: a white-list type firewall,
> which drop all connections unless stated otherwise. It's intended for
> a simple workstation.
>
I can read and rewrite rules, I use nftables very well, trust me. I submit this bug is not about the nftable rules, it is about what config file used as default should be. I think it should be blank. We use debian on any cloud platform, somedays later, more and more, but we make image can not login remote as default, it is not cool. This config is just an example, or some about author's opinion at workstation, but it is should not use as default.
> You should not enable the firewall without reading the ruleset first.
Yeah, I am not really lost my remote system, just because I had read the rules and modified.
> That's why the user has to manually enable the nftables systemd service.
>
> Regarding the /etc/nftables directory: it should not be there, and the
> next package upload to debian will not carry the directory.
>
no no. This is another wrong way. firewall is core component, config files can be more, and change frequent. You can split config files like sysctl, put them in nftables.conf and nftables.d. Try to do this.
> --
> Arturo Borrero González
Arturo Borrero Gonzalez
* I will drop the sysvinit support, perhaps I will still ship the init
script as a example.
* I will delete the /etc/nftables/ directory. If you need a custom
shape for your firewall, you have to create it manually. It's not the
package matter.
* I will relax the default firewall configuration. I will provide an
empty firewall by default, and will add real-life examples.
thanks.
--
Arturo Borrero González