Figure 6.9: System overview..
(See also Fig. 6.5 on page 57 for relations to the OS(I)-network-stack.)
The design relies on certain key properties, which can be summed up below:
• It is for ordinary users on Linux-platforms, so any tools, libraries and components used, must be readily available in any decent (and recent) Linux-distribution (RedHat, SuSE, debian, . . . ). No special re-compiled patches should be needed.
• The use of a Database is central in the design.
Firstly, it allows much larger amounts of data to stored (i.e. it scales better) and it allows cross-searching much more flexible that linked lists of objects (i.e. an STL-list containing strings of iptables-command-lines). This is what databases and SQL is designed for in the first place.
Secondly, by using a standard SQL-base, an established interface is used - no re-invention of the wheel here. Whatever and however the GUI operates on data, it has no impact on how parser- and generator-tools populate and traverses the database. Likewise, GUI-extensions and algorithms (Verifiers, Dialogs, Wizards, Views etc.) can use SQL-queries to extract the essential data only - or operate on all of it.
The result is that the database makes the parser- and generator-tools towards the system independent of the GUI-tools. And any GUI-extension have access to all the data they need,
since it isn’t possible to predict what data and interface should be made available to an future GUI-extension. And all in a standardised way: SQL.
• Dynamic XML-dialogs: This feature should allows us to create and distribute binaries of this project without the need to recompile individual modules handling a particular netfilter-module. The netfilter-modules are either part of the netfilter-package and is distributed a vendor, or the modules are created by a third part. It isn’t likely that they would know about the GUI-wrappers in this project. Therefore, this feature is paramount and necessitates the use of KDE/Qt, which have built-in support for such feature.
• Display and interaction of nice and presentable graphs: The need for a simple and pleasant view of the packet-flow is important. This is a direct measure of overview and usability which is one of the goals of this project. A firewall design tool could be seen as a editor of flow-diagrams for network-packets, and flow-diagrams are graphically represented using directed graphs.
Thedot-tool in the Graphviz-package contains several tools for working with directed graphs with long history and proven track-record stability-wise.
Thetulip-package is a larger and more extensible package that might be used instead since it seems to have pre-fabricated GUI-viewers and editors, along with the possibility of importing dot-graphs.
• Parsing (transformation) of data between the GUI-views, the database and system-commands (e.g. iptables): This means that we must understand (parse) the output of iptables to create (generate) the condensed graph to the user. The reverse step includes parsing the graph and create the necessary iptables-commands. The choice of parser-tool could have been Lex/Yacc (flex/bison). Or the more modern ANTLR, since it generates both Java- and C++-code with good debugging facilities using Java (with display of the parser’s internal abstract symbol-tree, AST), while retaining the C++-capability.
But currently, the parsing have been done ’by-hand’, using regular-expressions (QRegExp from Qt), since the parsed data haven’t been complex in states (the yacc-part), only in amount and symbol-diversity (the lex-part). And QRegExp is a fast and flexible class with capabilities close to those of e.g. sed/awk.
Chapter 7
Detailed Design issues
Here follows more detailed discussions on the design-choices and technologies deployed.
7.1 Knowledge discovery and acquisition
Some things may not be rocket science, but for the un-enlightened everything is difficult - i.e.
”The devil is in the details. . .”.
This incomprehensive list of issues are illustrating that point, in practical projects like this one:
• The development is taking place on Linux, using Open- and Free-Source. That added an extra dimension as far as documentation and ”knowledge finding”, because the API-, tutorial-and background-documentation of kernels tutorial-and libraries are ranging from excellent to non-existing. Some documentation is outdated - the source have moved on, some just not there - read the source-code.
That is different from commercial products, which strives to have uniform and updated documentation - although the actual descriptions may not be any better, at least it is there.
One does not seek or read in vain, is more simple: ”if it ain’t right here - we haven’t documented it at all.”
(Illustrated by the need to read multiple KDE-tutorials about the same issue, and read it along with the source-code - and then cross-correlate the information to filter out errors and uncover the issue.)
• As for Components and third party libraries (APIs): Knowing your components beforehand is an good idea. Otherwise one tends to go with the first component or API-library found for the task. But choosing the right components are essential. Remaking that choice may be initially wasteful, but later on it will have a heavy impact. Remember that the better API will be used all the time during development, and the inferior choice will have an exponential impact on effort and time - bad components and APIs may explode in difficulties, while good ones allows time and effort to be focused elsewhere.
Conclusion is: spend a little more time initially on getting the component-choices right - it will come back many-fold in saved time and efforts, increased functionality, better overview and planning-estimates - simply less problems and frustrations.
(Illustrated by the selection-process of a good database-API. Time was spent on trying out several libraries, and Qt turned out to have the better one - and it have, despite some inconsitentciesinconsistencies, saved many working hours later on.)
• Some components are white-boxed - others are black-boxed. Examples are the KDE- and Qt-libraries. Meaning, the documentation on some components (like KDE) are not sufficient, and one needs to read the code of the component - which makes it a white-box. Others (like
Qt) have excellent tutorials, examples and reference documentation and can be used without a need to know whats in them - i.e. black-boxed.
Using white-box components are only slightly better that ordinary code of any kind. It is only the design-part, which may have turned the component into a self-enclosed code-entity, where ordinary code may not have been crafted with such in mind.
As always - ones millage may vary - and the conclusion is that: without good documentation, components are only half a step up the software-development and -maturity ladder. Using them give you tested capability right out of the box, but the time invested in finding out how to use them, are same as with ordinary code - i.e. you got to deciferdecipher the design though reading the code.
(Illustrated by the usage of KListView-classes as the main view-widget in most of the components. It has very scares documentation and 5000 lines of code. In order to be able to use it, one must read and use the Qt-counterpartQListView first, in order to understand the new set of functions on the derived KListView - how to use them and why they are much better.)
The above points are present to some degree in every project, but was profound through out this project. It resulted in more time used on the above issues than initially expected - and that is whythe devil is in the details. . .
The remaining chapter deals with specific details encountered during the implemnetation-phase. The topics mostly follow the modules-bounderies of the system overview in Fig 6.9. We start off with the technology which enables modules in the first place (along with 3.-party extensions), - one of the core requirements of this project.