CentOS - Nov 2015 - firewalld being stupid

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'

On Nov 17, 2015 12:11 PM, <m.roth at 5-cent.us> wrote:
> tell me progress, and final result. You'd think they were an old New
> Englander.....
>
>          mark, ayu'
_____________________________

Totally hilarious. Thanks for making my day.

Mike

On 17.11.2015 17:51, m.roth at 5-cent.us wrote:
> 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.....
Systemd has better mechanisms to report feedback compared to SysV
scripts but if the creators of the service files and the daemons don't
make use of these that's hardly systemd's fault. The best way is to use
"Type=notify" which allows a daemon to actually report to systemd when
it is done initializing. If the daemon doesn't support this then you can
still use ExecStartPost to specify a command that verifies that the
daemon indeed did start up correctly (and no the binary returning a code
of 0 does not mean the service is actually up-and-running properly).

Regards,
  Dennis

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 17/11/15 17:29, Dennis Jacobfeuerborn wrote:
> On 17.11.2015 17:51, m.roth at 5-cent.us wrote:
>> 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.....
> 
> Systemd has better mechanisms to report feedback compared to SysV 
> scripts but if the creators of the service files and the daemons
> don't make use of these that's hardly systemd's fault. The best
way
> is to use "Type=notify" which allows a daemon to actually report
to
> systemd when it is done initializing. If the daemon doesn't support
> this then you can still use ExecStartPost to specify a command that
> verifies that the daemon indeed did start up correctly (and no the
> binary returning a code of 0 does not mean the service is actually
> up-and-running properly).
> 
> Regards, Dennis
> 
You may well be right.  However for those of us who just want to get
the system running it has lousy reporting.  Under SysV setting -vx on
the script gave meaningful output - there's no easy equivalent under
systemctl.  Systemctl returning success status on daemon failure is
plain stupid.  I'm sure systemd does wonderful things and is the
future and we're stuck with it now until at least CentOS/RHEL 8.  One
of the great joys of *NIX is small, stable text files that can be
handled without vast study unlike the obscure behemoth that would look
good coming out of Redmond.  Even getting ntp to supply time to
another system takes hours instead of 5 minutes.

If I ever meet Poettering I'll be sure to sup with a long spoon. ;-(
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJWS5ksAAoJEAF3yXsqtyBlA1oQANrvHWI3JbGUfREfZWYUiRxi
ZTP3rATIyXwbmgK7ApcanAXqrnF1M1PmSarmnLQFhaNdNI1an5YdT/qM5tpnBUwg
MemJSUNZHPAxdg8KDqRr2alb0jLK/GHALO+43XaEQN3CMZfZbz2rU6xKToNtF4GP
YK2o+UdPGnpvs8fj8kXkIiLiBn6rc9pBl0MABLnfdqvS13LggrUPFVhcc6oyH2FS
IgQk8rmOgFaiiqKb5r3hRpWvVbDpBo+J4CiHa0qI3d3R4OgDgZHFLfwX0CJCjbty
Kkoe/qJgNwHXnHwlJ7ZyEgx+ARKTI8Wii8S7sM0ZSAaAnkdf1SltC8DXn0jKCUKo
7Q5eYzNuf86XOfGCjrLG57Hy7v8aQG3NVa4pLFrhKUvEIjNvE14DePX18bp3Y7Yv
aKhBdnu/UVkSvoriCLCAtbVnZvKv6Jj6v9ayW6Ke/Uyfphs24m0KCM4rlMQjH9hj
IsD6qJVc2yfLQMZ9OL8emusXLRAmRf002oWVtFrBaskdL9GFkG00eMewADyFyM2r
HUlkcGdP4EsFaPF74spRjhY4sl+PRQ3Hl3QyQ5xz51N8+bnuua3Dv5gniDDeqMc/
3pa4IZAReYN6drO7dKBmh2AGqVX7C8JZJDsJ5kb8PN0O4L2SAq/V4rB3lb1w/WoY
TH9EcBGRtdmNxsF801Ah
=QOQq
-----END PGP SIGNATURE-----