... | ... | @@ -55,24 +55,24 @@ These are the values terms used in this document. |
|
|
* **ANA**: Authorization and Authentication component of Stork. It provides mechanism to verify that the user has permissions to access the system and specifies what the user can do in the system. **ANA** component also provides means for the super user to create new users and define their permissions.
|
|
|
<<<<<<< HEAD
|
|
|
* **Application**: A **Program** or a group of **Programs** providing some functionality. For example, the Kea **Application** comprises of several **Daemons**, including the control agent and the dhcpv4 daemon. An **Application** of the same type can not run more than once on the same **Machine**.
|
|
|
* **Daemon**: A software component that is part of an **Application**. For example, the *named* deamon is part of the BIND9 **Application**. In the case of Kea, a *kea-dhcp4* is also a *Daemon*. The deamon may be *active* (running) or *inactive* (not running). The deamon may be inactive on purpose (because it is optional or not needed in the current configuration) or may be inactive because of a failure.
|
|
|
* **Daemon**: A software component that is part of an **Application**. For example, the *named* daemon is part of the BIND9 **Application**. In the case of Kea, a *kea-dhcp4* is also a *Daemon*. The daemon may be *active* (running) or *inactive* (not running). The daemon may be inactive on purpose (because it is optional or not needed in the current configuration) or may be inactive because of a failure.
|
|
|
=======
|
|
|
* **Application**: A **Program** or a group of **Programs** providing some functionality. For example, the Kea application comprises of several daemons, including the control agent and the dhcpv4 daemon. An **Application** of the same type can not run more than once on the same **Machine**.
|
|
|
* **Current State**: is a collection of runtime information about the application, deamon or service which provides the details about its operation and allows for making determination whether it is operating as desired or with issues. It also includes the information about the issues.
|
|
|
* **Current State**: is a collection of runtime information about the application, daemon or service which provides the details about its operation and allows for making determination whether it is operating as desired or with issues. It also includes the information about the issues.
|
|
|
>>>>>>> dfd80568315a6ea01a649550bb7da1a8f0b254cb
|
|
|
* **Component**: A functional part of the system. It can be a third party software integrated with Stork (e.g. Prometheus, Logstash instance, database instance) or it can be a part of Stork distributed on remote machines, e.g. **STAG**.
|
|
|
* **Condition**: is a boolean-like information about the deamon, application or service indicating if it is in the desired state or not. The two possible values are: `healthy` and `unhealthy`. The determination whether it is in one of the two is made by examining the current state vs desired state. The condition may be accompanied by a brief description of the problem which gives a hint to the user why the deamon, application or service is unhealthy.
|
|
|
* **Daemon**: A software component that is part of an application. For example, the *named* deamon is part of a BIND9 application. In the case of Kea: a *kea-dhcp4* is also a deamon. The deamon may have the `running` or `not running` status. The deamon may have `not running` status on purpose (because it is optional or not needed in the current configuration) or because of a failure. Whether it is not running on purpose or because of the failure can be determined by examining the desired state of the deamon.
|
|
|
* **Desired State**: is a collection of information about an application, deamon or service which define how the administrator wants the application, deamon or service to behave. A set of parameters belonging to the desired state may not be the same as the set of parameters describing the current state, because the current state may include some diagnostic information, e.g. CPU utilization or application uptime. However, it must be always possible to determine whether the application, service or deamon is in the desired state by examining the current state.
|
|
|
* **Condition**: is a boolean-like information about the daemon, application or service indicating if it is in the desired state or not. The two possible values are: `healthy` and `unhealthy`. The determination whether it is in one of the two is made by examining the current state vs desired state. The condition may be accompanied by a brief description of the problem which gives a hint to the user why the daemon, application or service is unhealthy.
|
|
|
* **Daemon**: A software component that is part of an application. For example, the *named* daemon is part of a BIND9 application. In the case of Kea: a *kea-dhcp4* is also a daemon. The daemon may have the `running` or `not running` status. The daemon may have `not running` status on purpose (because it is optional or not needed in the current configuration) or because of a failure. Whether it is not running on purpose or because of the failure can be determined by examining the desired state of the daemon.
|
|
|
* **Desired State**: is a collection of information about an application, daemon or service which define how the administrator wants the application, daemon or service to behave. A set of parameters belonging to the desired state may not be the same as the set of parameters describing the current state, because the current state may include some diagnostic information, e.g. CPU utilization or application uptime. However, it must be always possible to determine whether the application, service or daemon is in the desired state by examining the current state.
|
|
|
* **LAR**: Locally Applicable Resource, a resource which is stored in the **StorkDB** and not on the remote machine.
|
|
|
* **Program**: Synonym of deamon.
|
|
|
* **Program**: Synonym of daemon.
|
|
|
* **Machine**: A machine running one or more **Services** which Stork connects to.
|
|
|
* **RAR**: Remotely Applicable Resource, a resource which is used and stored on the remote machine besides being stored in **StorkDB**.
|
|
|
* **Resource**: Representative piece of information typically stored in the StorkDB, upon which CRUD operations can be performed. Example of resources: Stork user, subnet, DNS zone.
|
|
|
* **Service**: A set of **Applications** that interact together to provide something useful for the end user. For example, the DHCP service may have several kea **Applications** to provide High Availability. A **Service** is managed by Stork via an API, e.g. DHCP service, DNS service, Prometheus instance.
|
|
|
* **STAG**: Stork Agent, a deamon running on Machine which manages Services local to this machine. Example functions of **STAG**: report software versions, perform **Service** upgrades.
|
|
|
* **STAG**: Stork Agent, a daemon running on Machine which manages Services local to this machine. Example functions of **STAG**: report software versions, perform **Service** upgrades.
|
|
|
* **StorkDB**: PostgreSQL database used by Stork to store critical information about Stork itself (e.g. configuration information) and about other components of the system, such as managed servers, network topology, users with their credentials and many more.
|
|
|
* **Status**: is a boolean-like information indicating whether a deamon or service has been started and hasn't terminated. There are two `status` values defined: `running` or `not running`.
|
|
|
* **Status**: is a boolean-like information indicating whether a daemon or service has been started and hasn't terminated. There are two `status` values defined: `running` or `not running`.
|
|
|
* **StorkCLI**: Stork command line interface, a command line tool which can be used instead of the **StorkUI** to manage the system.
|
|
|
* **StorkUI**: The graphical user interface provided by Stork and available to the user via web browser.
|
|
|
* **Supported Software**: The software installed on **Machine** and providing services that Stork has integration with, e.g. Kea software, BIND software, Prometheus software etc.
|
... | ... | @@ -262,7 +262,7 @@ When the new server is being added to the system, the information about this ser |
|
|
|
|
|
## Daemons, Applications, and Services
|
|
|
|
|
|
What exactly is a **Service**? A **Service** is one or more **Applications** running on the network that provides some capability. An **Application** is one ore more **Daemons** that together provide the desired functionality. For example, the DHCP service may have multiple kea **Applications** running in different modes in order to provide High Availability. A kea **Application** constists of multiple **Daemons**, such as the Control Agent, the DHCPv4 daemon, the DHCPv6 daemon and the DDNS daemon.
|
|
|
What exactly is a **Service**? A **Service** is one or more **Applications** running on the network that provides some capability. An **Application** is one ore more **Daemons** that together provide the desired functionality. For example, the DHCP service may have multiple kea **Applications** running in different modes in order to provide High Availability. A kea **Application** consists of multiple **Daemons**, such as the Control Agent, the DHCPv4 daemon, the DHCPv6 daemon and the DDNS daemon.
|
|
|
|
|
|
It is important to acknowledge that there are different presentations of an **Application**. One view is that an **Application** is something that is running on a **Machine** and has a particular state (Active or not, configuration).
|
|
|
Another way to look at it is that the **Application** itself dictates the configuration and the **Daemons** running on a **Machine** represent an instance of that **Application**. That instance also has a state and hopefully matches
|
... | ... | @@ -439,7 +439,7 @@ The respective lines have the following meaning: |
|
|
|
|
|
Note that the policy file both defines user permissions and also associates some of the users with groups (roles). Neither the user names nor the resource names are validated by casbin enforcer. It is up to the application to validate the user names (also perform authentication) and the resource names. The policy file is read (typically when the application is launched) and the enforcer uses this data for authorization. Adding the new policy entries to the file will not take effect until the application is reloaded. Therefore, casbin provides a simple API to add new policy entries. The updated policy can be saved into the file (or other storage).
|
|
|
|
|
|
There are [storage adapters](https://casbin.org/docs/en/adapters) available, contributed by casbin users. One of them is [casbin-pg-adapter](https://github.com/MonedaCacao/casbin-pg-adapter) - which works with the [go-pg adapter](https://github.com/go-pg/pg), considered in this design as the ORM library for Stork. The casbin policy file uses CSV format. The way that the adapters seem to store the policy in the database reflects the CSV file structure. The policy is stored in the single table and this table is dropped and recreated (with updated policy) upon the policy update.
|
|
|
There are [storage adapters](https://casbin.org/docs/en/adapters) available, contributed by casbin users. One of them is [casbin-pg-adapter](https://github.com/casbin/casbin-pg-adapter) - which works with the [go-pg adapter](https://github.com/go-pg/pg), considered in this design as the ORM library for Stork. The casbin policy file uses CSV format. The way that the adapters seem to store the policy in the database reflects the CSV file structure. The policy is stored in the single table and this table is dropped and recreated (with updated policy) upon the policy update.
|
|
|
|
|
|
The [casbin API documentation](https://casbin.org/docs/en/management-api) describes all API calls being supported. It is possible to fetch policies for the particular user or group. It is also possible to check whether the user has certain permissions based on grouping policy or user specific policy.
|
|
|
|
... | ... | |