The man page says that "--enable-panic" will enable panic mode. Fine. Unfortunately, so will "--enable", or even "--e". That is _not so good_.
I've been looking at rewriting firewall-cmd to use argparse module, which should help with bug #879834 and bug #876394, comment #2. I had been thinking it would fix also this problem until I found http://docs.python.org/dev/library/argparse.html#argument-abbreviations which says that long options are abbreviated if the abbreviation is unambiguous and error is produced only for arguments that could produce more than one option. So in your case "--enable", or even "--e" are OK and should actually do the same as "--enable-panic" because there's no other option beginning with "--enable", or even "--e".
Workarounds: A) Don't use "enable" for "panic". Enable means to allow or make possible, so it is kind of backwards for "enable" to actually disable the normal operation. B) add some other command that also starts with --enable.
Real-world example of someone other than me being confused and bitten by this: http://serverfault.com/questions/478148/fedora-linux-18-firewalld-blocking-all-ports-after-firewall-cmd-enable
(In reply to comment #2) > A) Don't use "enable" for "panic". Enable means to allow or make possible, > so it is kind of backwards for "enable" to actually disable the normal > operation. I've been thinking about this, but the only idea I have is: --enable-panic ~~> --panic-enable or --panic-start or --panic-on --disable-panic ~~> --panic-disable or --panic-stop or --panic-off --query-panic ~~> --panic-query This solves the original problem, on the other hand it makes the options heterogenous as all the other have --verb-noun form.
(In reply to comment #4) > This solves the original problem, on the other hand it makes the options > heterogenous as all the other have --verb-noun form. "Panic" _is_ a verb. :)
Changed upstream http://git.fedorahosted.org/cgit/firewalld.git/commit/?id=df08c08dfd9fa0ea366fd9d4d2b043d2ae7027c3
Fixed since 0.3.0