The openATTIC core makes heavy use of the Django framework and is implemented as a Django project, consisting of several apps, one for each supported functionality or backend system.
Each app bundles a set of submodules. Models are used to represent the structure of the objects an app is supposed to be able to manage. The REST API (based on the Django REST Framework is used for interaction with the models. And lastly, the System API can be used in order to run other programs on the system in a controlled way.
When an application (e.g. the openATTIC Web UI, a command line tool or an external application), wants to perform an action, the following happens:
- The REST API receives a request in form of a function call, decides which host is responsible for answering the request, and forwards it to the core on that host.
- The openATTIC Architecture consists of two layers:
- Django Models, the brains. They keep an eye on the whole system and decide what needs to be done.
- File system layer: Decides which programs need to be called in order to
implement the actions requested by the models, and calls those programs
via the openATTIC
systemdbackground process (not to be confused with the Linux operating system’s systemd System and Service Manager).
- The openATTIC
systemdexecutes commands on the system and delivers the results.
Models are used to provide an abstraction for the real-world objects that your app has to cope with. They are responsible for database communication and for keeping an eye on the state of the whole system, being able to access any other piece of information necessary.
Please check out Django at a glance for more information.
openATTIC systemd background process¶
Some tasks require root privileges for being performed. In openATTIC, this is done
via a separate background process
openattic-systemd, written in Python. The
Django web application uses
DBUS as a bidirectional communication channel
to this background service.