On Mon, November 16, 2015 16:39, Nick Bright wrote:
> On 11/6/2015 3:58 PM, James Hogarth wrote:
>> I have a couple of relevant articles you may be interested in ...
>>
>> On assigning the zone via NM:
>> https://www.hogarthuk.com/?q=node/8
>>
>> Look down to the "Specifying a particular firewall zone" bit ...
>> remember that if you edit the files rather than using nmcli you must
>> reload NM (or do nmcli reload) for that to take effect.
>>
>> If you specify a zone in NM then this will override the firewalld
>> configuration if the zone is specified there.
>>
>> Here's some firewalld stuff:
>> https://www.hogarthuk.com/?q=node/9
>>
>> Don't forget that if you use --permanent on a command you need to do
>> a
>> reload for it to read the config from disk and apply it.
> Thanks for the articles, they're informative.
>
> Here's what's really irritating me though.
>
> firewall-cmd --zone=internal --change-interface=ens224 --permanent
>
> ^^ This command results in NO ACTION TAKEN. The zone IS NOT CHANGED.
>
> firewall-cmd --zone=internal --change-interface=ens224
>
> This command results in the zone of ens224 being changed to internal,
> as
> desired. Of course, this is not permanent.
>
> As such, firewall-cmd --reload (or a reboot, ect) will revert to the
> public zone. To save the change, one must execute firewall-cmd
> --runtime-to-permanent.
>
> This is very frustrating, and not obvious. If --permanent doesn't work
> for a command, then it should give an error - not silently fail
> without doing anything!
>
This behaviour is congruent with SELinux. One utility adjusts the
permanent configuration, the one that will be applied at startup.
Another changes the current running environment without altering the
startup config. From a sysadmin point of view this is desirable since
changes to a running system are often performed for empirical testing.
Leaving ephemeral state changes permanently fixed in the startup
config could, and almost certainly would eventually, lead to serious
problem during a reboot.
Likewise, immediately introducing a state change to a running system
when reconfiguring system startup options is just begging for an
operations incident report.
It may not be intuitive to some but it is certainly the logical way of
handling this.
--
*** e-Mail is NOT a SECURE channel ***
Do NOT transmit sensitive data via e-Mail
James B. Byrne mailto:ByrneJB@xxxxxxxxxxxxx
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
