Sharing Objects

6. Sharing Objects

If you run ipfilter on several hosts, their rulesets probably use common objects, such as your routers, servers, subnets on your site, some frequently used services, etc. To avoid redefining the same objects in different rulesets:

you can import the objects of one ruleset into another
you can use objects include files shared by several rulesets
or if you have few common objects, a quick and dirty means is to copy/paste the objects from one ruleset to the other.

Contents

Importing objects
Importing: conflicts
Include files
Include files: conflicts
Including vs. importing

Importing objects

At any time you like in your ruleset's lifecycle, you can import objects from another ruleset by using the File menu. You select the ruleset that contains the objects you want to import, say, foo.isba, and these are all copied in your current ruleset. Then you can modify them as you wish.

Note: only the "native" objects of foo.isba are imported: if foo.isba uses objects from include files, these are not copied.

If you want to import only a few objects of foo.isba, see Copy/Paste between rulesets.

Importing: resolving objects conflicts

An object conflict occurs where an imported (or included, see below) object has the same name as an object of the current ruleset, and where the objects are different. If both objects are strictly the same (name, value, comment, color), there is actually no conflict so isba silently ignores this case. Moreover, if one of the objects has no defined value, it is silently overridden.

What to do in the event of an object conflict ? You decide it just before importing, in the 'Import from ...' popup. You have three options:

Importing: conflicts

ask me: for every name conflict, a window pops up and you must choose to either keep your ruleset's object or to replace it with the imported one
replace with new object: for every name conflict, your ruleset's object is replaced by the imported one
keep old object: objects are not imported if a local object has the same name.

Importing popup: the three options for conflict resolution

Include files

Isba include files works like C include files: somewhere in your ruleset (preferably at the beginning), you specify in a comment rule which file(s) you want to include objects from, with the keyword '#include-objects':

Gui tips

From your main ruleset isba window, you can quickly edit your rulesets's include files in a new isba session: in the File menu, choose 'Open include file'. The list of your ruleset's include files appears in a cascaded menu, choose the one you wish to modify.

Including objects files

Include files are simply isba source files with objects and (preferably) no rules. To create an include file you simply make a new ruleset, create objects, save it and there you have it!

Object including may be recursive: include files may contain '#include-objects' directives.

Creating an include file

All include files are read when you open the ruleset. So when you add or change an '#include-objects' directive in your ruleset, you must save and reopen it in order to load the included objects.

Changing #include-objects directives

Similarly, if you are editing your ruleset and if you change an object in an include file (in another isba window), you must reopen your main ruleset in order to refresh the included objects.

Changes in include files

Include files: resolving objects conflicts

An object conflict may occur either between an object belonging to your main ruleset and an included object, or between two included objects coming from different include files.

Objects conflicts

In the latter case, isba simply keeps the last read object and prints a warning on stdout.

In the former case, the conflict resolution depends on a Preferences choice (see Objects Preferences): if you chose 'included objects can't be redefined in local ruleset', then the included object overrides the ruleset object, otherwise the ruleset object is retained. Isba prints a warning on stdout in both cases.

Let's look more precisely at the three choices you have in the Preferences window:

Included objects conflicts resolution: preferences options

Suppose you have opened a ruleset with included files, and you want one of the included objects to be different for this specific ruleset. You edit the object, modify it and click 'Create' (and not 'Update', which is disabled because you can't modify included objects). Actually you can do that only if you chose the second or third line in the Preference choice above.

Overriding an included object

Including vs. importing

Including is different from importing for two reasons:

interactivity
objects importing is an operation you do interactively when you decide to, whereas objects including is hard-wired in a comment line of the ruleset. The objects from the included file are read when the ruleset is opened.

read-write or read-only
imported objects are copies. The advantage is that they may be modified in the edited ruleset; the drawback is that multiple copies of the same object must be maintained. On the other hand, included objects are read-only (actually, may be read-only ... see previous section)

Including vs. importing

As a conclusion, the most maintainable way of sharing objects is to use included files and to prohibit the redefinition of included objects in Preferences.