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 at Harte-Lyne.ca 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
On Tue, Nov 17, 2015 at 09:18:22AM -0500, James B. Byrne wrote:> 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.Another possible reason is because when you're setting up firewalld, you might want to batch a bunch of changes with --permanent, then, once you've added them all, *then* you restart firewalld to pick up the changes. Having the firewall restart after *every* permanent change you want to make would leave the system's firewall bouncing up and down. -- Jonathan Billings <billings at negate.org>
On 17.11.2015 15:18, James B. Byrne wrote:> > 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. >The better way is to explicitly allow the user to dump the runtime configuration as the persistent configuration though as that makes it much more difficult to have subtly diverging configurations due to user errors. On network switches you often find something like "copy running-congig startup-config". Regards, Dennis
On 11/17/2015 8:18 AM, James B. Byrne wrote:> 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.I certainly don't disagree with this behavior. What I disagree with is documented commands _*not working and failing silently*_. -- ----------------------------------------------- - Nick Bright - - Vice President of Technology - - Valnet -=- We Connect You -=- - - Tel 888-332-1616 x 315 / Fax 620-331-0789 - - Web http://www.valnet.net/ - ----------------------------------------------- - Are your files safe? - - Valnet Vault - Secure Cloud Backup - - More information & 30 day free trial at - - http://www.valnet.net/services/valnet-vault - ----------------------------------------------- This email message and any attachments are intended solely for the use of the addressees hereof. This message and any attachments may contain information that is confidential, privileged and exempt from disclosure under applicable law. If you are not the intended recipient of this message, you are prohibited from reading, disclosing, reproducing, distributing, disseminating or otherwise using this transmission. If you have received this message in error, please promptly notify the sender by reply E-mail and immediately delete this message from your system.
Nick Bright wrote:> On 11/17/2015 8:18 AM, James B. Byrne wrote: >> 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. > > I certainly don't disagree with this behavior. > > What I disagree with is documented commands _*not working and failing > silently*_. >I agree, and it seems to be the way systemd works, as a theme, as it were. I restart a service... and it tells me *nothing* at all. I have to run a second command, to ask the status. I've no idea why it's "bad form" to tell me progress, and final result. You'd think they were an old New Englander..... mark, ayu'