Date: Fri, 04 May 2018 01:23:03 +0300 From: Alexander V. Chernikov <melifaro@ipfw.ru> To: Julian Elischer <julian@freebsd.org>, Rodney W. Grimes <freebsd-rwg@pdx.rh.cn85.dnsmgr.net> Cc: "freebsd-ipfw@freebsd.org" <freebsd-ipfw@freebsd.org>, Oleg Bulyzhin <oleg@freebsd.org>, Andrey V. Elsukov <ae@freebsd.org> Subject: Re: removing some error states Message-ID: <11885361525386183@web50g.yandex.ru> In-Reply-To: <30b5e916-60ef-c3fa-1f80-5858d0d6717c@freebsd.org> References: <201805011503.w41F3PxP026423@pdx.rh.CN85.dnsmgr.net> <81ced915-4dae-26c0-bc43-5ff5299d00d0@freebsd.org> <30b5e916-60ef-c3fa-1f80-5858d0d6717c@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
02.05.2018, 06:32, "Julian Elischer" <julian@freebsd.org>: > On 2/5/18 1:05 am, Julian Elischer wrote: >> On 1/5/18 11:03 pm, Rodney W. Grimes wrote: >>>> Many years ago I added code to ipfw so that if -q was set it would >>>> not >>>> complain about >>>> things that were unimportant, nor would it return an error code. >>>> Such things include removing table entries that are already gone and >>>> similar sorts of 'safe' operations. >>>> The idea is that you can write 'naive' scripts that don't need to do >>>> complicated checks to see if XXX is already present or gone.. >>>> In hte ame way that rm -f doesn't complain if the file doesn't >>>> exist..? You were going to delete it anyhow. >>>> >>>> I'd like that to continue to some of the new additions. >>>> for example the terribly annoying >>>> ??? ipfw: DEPRECATED: inserting data into non-existent table 18. >>>> (auto-created) (who cares?) >>>> >>>> and >>>> >>>> ?? ljcc-78# ipfw table 19 create >>>> ???? ipfw: Table creation failed: File exists >>>> >>>> As the script needs to run multiple times, I don't care if the table >>>> already exists. >>>> but I do care about other errors. >>>> I don't want to have to write special wrapper code for table create >>>> that is different >>>> from the wrappers elsewhere because it has to look for return code 71 >>>> and disregard it. >>>> Can we just have -q continue to ignore such errors please? >>> I think there is a bigger question here, why was auto table creation >>> with first insert "Deprecated" at all? This to me just seems like >>> change cause someone could change it that has no usefull purpose or >>> is there some great purpose this serves? In the "old" world we had single type of tables, each of them name by numbers from 1.. ip.fw.tables_max range. If the table number was less than ip.fw.tables_max - it automatically existed. If not, one had to increase ip.fw.tables_max. In the new world, number of different table types / configuration is pretty large. Additionally, one can use string names as table identifiers. In most cases, user wants to have "old" kind of table with default values, but it might not always be the case. Let's suppose one wants to have special kind of table, but forgots to create it. Then, silently creating default table upon insertion will simply hide an error leading to undesired hard-to-dianose behaviour on later stages. >>> >>> Same with creation of an already existing file, why did that need >>> to become a noisy warning/error? >> Well ther eis an argument (that I disagree with in this case) that >> any unexected even is an error.. >> >> Also the new tables can have many different key type and indexing >> algorithms, which need to be declared up front. >> >> but I don't see that raising a fatal error for trying to delete >> something that doesn't exist or make something that already exists >> really helps much other than to make scripts more complicated. >> That's why I made it optional before.. Removing table entries that >> are not present could be an error you want to know about, but >> probably it isn't. The question here is what is the desired level of "smartness" ipfw(8) should implement. Traditionally it was a pretty low-level tool, used by other scripts/tools to manipulate the ruleset. In that case then generic idea is that we should propagate the error, so one can handle it properly in the upper layer. > > my biggest issue is that it bombs out when you are using it as a filter. > e.g. (manual simulation) I understand your frustration. The original changeset for the named tables was pretty big and I was mostly focused on fixing the kernel and providing backward compatibility, so some of the ipfw(8) stuff were not though thoughtfully. Let's discuss/agree on the desired behaviour and fix it. > > 32Ssd# ipfw -q -f /dev/tty <---- -q "don't complain and quit on > unimportant things -f "trust me I know what I'm doing" I always thought of "-q" meaning as mostly "Be quiet when executing ..." as ipfw(8) manual states, which is different from the generic "ignore errors". I totally agree that having some way of saying "ignore the error and continue" is a thing we should have. Probably, adding another option for that would be an overkill, so we indeed can rebrand "-q". > table 3 add 1.1.1.1 > table 3 add 1.1.1.1 <- no error.. this is what I want.. > table 20 add 2.2.2.2 > table 3 swap 20 > table all list > --- table(3), set(0) --- > 2.2.2.2/32 0 > --- table(20), set(0) --- > 1.1.1.1/32 0 > table 3 swap 21 <-- doesn't quit, but doesn't generate a new > empty 21 either :-( What is the "proper" behaviour from your pov here? (with and without -q)? > table all list > --- table(3), set(0) --- > 2.2.2.2/32 0 > --- table(20), set(0) --- > 1.1.1.1/32 0 > table 21 create > table 21 create <------ this shouldn't quit.. actually I This shouldn't quit IFF "-q" is supplied and the already-created table is absolutely the same in terms of types, algorithms and values? > wouldprefer that I didnt NEED to make the damned things. Any reference > should make it.. (e.g. swap) > Line 6: Table creation failed: File exists > 32Ssd# > "congratulations the parent process now has to restart it.." > > The Cisco/Ironport "Web Security Appliance" ran like this, with a > python process feeding commands into a single instance of ipfw. > I don't know if it still does (Doug Ambrisko may know). I use this > method of running ipfw regularly, as forking and exec-ing a new copy > of ipfw for every firewall operation is a huge waste of resources when > you have a dynamic firewall that is constantly adding and removing > table entries and rules, as well as doing load control with dummynet. > Last thing I need is for ipfw to start quitting on operations that > should be idempotent. > > interestingly the man page no longer shows how to run with input from > a file in hte synopsis (though it refers to it) > > LIST OF RULES AND PREPROCESSING > To ease configuration, rules can be put into a file which is > processed > using ipfw as shown in the last synopsis line. An absolute > pathname must > be used. The file will be read line by line and applied as > arguments to > the ipfw utility. > > errr, no such example. > I think I will look into adding a -F option to allow for input from > a file or stdin.. > and make it shut the heck up in that mode (implies -q and -f) > > Julian > >> _______________________________________________ >> freebsd-ipfw@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?11885361525386183>