Table of Contents
List of Examples
Copyright (c) 2007 Connexion project, Peter V. Saveliev.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license can be found on the GNU site[1].
Mohan Sundaram — documentation proofreading.
Zalewsky Denis — documentation proofreading.
The main goal is to create a framework for system administration applications development. The framework should be friendly for users as well as for applications developers. System administration makes use of many heterogeneous applications, and it is important to provide an easy way for software interaction, and high rate of code reuse. All this can be achieved only using stable protocols and APIs within the limits of a rather common model.
Here are the distinct goals of the Connexion project. Some of them have been met while others are planned in the roadmap.
administration of a node (host) as well as a node set
support for multiple user interfaces (within the reasonable limits :)
transaction rollbacks, and/or exception handling
support for native modules as well as for external ones (scripts, executables, ...)
modules access control
The Connexion framework consists of:
The core, an application named connexion, provides interaction between system components and all high-level logic required for modules operation
Modules are programs that implements low-level logic. Encapsulating particular program calls, modules provide (via interfaces) the same command set across different systems. E.g., in Connexion, network interface setup commands can be the same for GNU/Linux and FreeBSD, though OS program calls differ.
Components that implements interaction between the core and users. Because of a stable and simple API, interfaces can be created for theoretically any interaction model. Thus, the same command sets will be available via different interfaces.
Connexion uses a tree for data representation. Every tree node corresponds to a command.
Nodes can be:
unique in a whole tree (e.g. loopback interface command)
unique in a branch (e.g. ethernet interface speed)
not unique (e.g. interface address)
There are cases when a command can be available in any branch (e.g. filter
command on) or strictly owned by branch (all interfaces accessible only
in interfaces branch).
All these properties are controlled by modules where the commands are described.
While processing commands Connexion recursively iterates over the tree, building the “environment” and calling module methods. During the processing each node can modify “environment” and modifications become available to parent, sibling or child nodes. Collaboratively, nodes build a system description can be translated into a shell-code and executed by services. The shell-code execution result (or output) can be redirected to user interface.
Described below is an example of building simple network settings. I want to mention each node is
created by corresponding command and module. This allows to reuse (import) e.g. the code for
address instructions procession in different interfaces or the IP-packet
classification/matching code both in trafic shaping and firewall branches.
Example 1. Simple network settings
! ! Comments are started with literal "!". Strictly speaking, ! literal "!" is a command too, and is described in a ! separate module in the base dictionary. A string after ! "!" is a command parameter. ! configure network ! interfaces ! ethernet 0 address 10.0.0.1/24 address 10.0.0.2/24 ! loopback enable ! routing table main route 192.168.0.0/16 via 10.0.0.127 route default via 10.0.0.128
Any node in the tree can generate so called “signals” either in a synchronous or asynchronous manner. The former is done while commit command is running, the latter can be done, e.g., with the internal socket monitoring engine. Here is an example of asynchronous signal emitting and handling:
Example 2. SNMP traps handling
! ! Catch a SNMP trap signal ! catch snmp if snmpTrapOid=linkUp if community=bala ! ! Restart an external service on signal ! exec /etc/init.d/pptp restart ! ! Register event listeners ! events ! ! 192.168.0.10 — interface to listen on ! snmp 192.168.0.10 port 1162
API and protocols should be simple and stable. Connexion uses XML-RPC for interaction with interfaces. XML-RPC is an extremely simple protocol, implemented for most programming languages. It means that interfaces can be written in any programming language developer wants. RPC API stability guarantees any core changes will not require interfaces to be rewritten. DBus support is planned additionally to XML-RPC.
The same can be said about modules. High level of abstraction and API stability permits to write modules independent on user interfaces changes.
Common data model. Tree representation is a well-tried abstraction, that enables high level of code reuse by module import from different tree branches. This also promotes stability and consistency of code.
Data types verification. The Connexion core does not only store command nodes and calls its methods. It also provides an API for parameters processing and data verification. E.g. a command that expects an IP-address as the first parameter will get valid IP-address. All other values will be rejected by the core.