diff --git a/docs/nmaas-applications/application-list.md b/docs/nmaas-applications/application-list.md index 1af736e7d9082ed25b91f27eaf5a8df49c0f0a58..3332eba5082d7b42c1966c727f4ce8808272d8e0 100644 --- a/docs/nmaas-applications/application-list.md +++ b/docs/nmaas-applications/application-list.md @@ -1,6 +1,6 @@ # List of Supported Applications -This is a continuously updated list of currently supported applications on NMaaS. Note that not all applications are supported across all environments, some are supported only on the managed server, while others can only be supported on self-hosted installations. +This is a continuously updated list of currently supported applications on nmaas. Note that not all applications are supported across all environments, some are supported only on the managed server, while others can only be supported on self-hosted installations. | No | Application name | Helm chart name | App Version (Helm chart version given in brackets) | Environment | |:--:|:------------------------------------:|:---------------------------------------:|:------------------------------------------------------------------------------------------------------------------------------------------:|-----------------------| diff --git a/docs/nmaas-applications/general-app-deployment.md b/docs/nmaas-applications/general-app-deployment.md index a95589fd82f6c8dd34544cfb6595c80bc38ea6d9..4423ae973d5788ba367fc0c866a1bc922455b886 100644 --- a/docs/nmaas-applications/general-app-deployment.md +++ b/docs/nmaas-applications/general-app-deployment.md @@ -1,12 +1,12 @@ # General Application Deployment -This page explains the basic set of steps that need to be undertaken during application deployment on NMaaS. +This page explains the basic set of steps that need to be undertaken during application deployment on nmaas. -## NMaaS Tool Deployment Process +## nmaas Tool Deployment Process -A basic set of steps required to deploy an instance of an NMaaS application is the following: +A basic set of steps required to deploy an instance of an nmaas application is the following: -1. Log in to NMaaS Portal +1. Log in to nmaas Portal 2. Choose application from the market 3. Request deployment and provide a custom name for the new instance 4. Follow the automated installation steps @@ -19,7 +19,7 @@ The whole process shouldn't take more than several minutes.  -## NMaaS Tool Configuration Process +## nmaas Tool Configuration Process During the tool deployment process user is asked to fill in a form and provide basic configuration data for the new tool instance. @@ -34,10 +34,10 @@ From this point any change to the configuration of a running tool instance shoul 3. Apply desired modifications, commit and push altered files back to the remote repository. 4. Wait for a couple of minutes in order for the new configuration to be loaded and applied by the tool instance. -Note: Git repositories containing application configuration files are hosted on a dedicated private GitLab instance operated by the NMaaS Team. +Note: Git repositories containing application configuration files are hosted on a dedicated private GitLab instance operated by the nmaas Team. Note: Users should upload their public SSH key using the Profile page before deploying a new instance of a tool in order to be able to clone the Git repository afterwards. ## Specific Application Tutorials -Tutorials for each of the supported applications currently in the NMaaS catalog are available in the [Application Deployment Tutorials Section](./tutorials/librenms.md). \ No newline at end of file +Tutorials for each of the supported applications currently in the nmaas catalog are available in the [Application Deployment Tutorials Section](./tutorials/librenms.md). \ No newline at end of file diff --git a/docs/nmaas-applications/new-application.md b/docs/nmaas-applications/new-application.md index 37085d12621e29cb285b8fd1e286bd74cc1fcb5d..3d1780a8a3ecd0b21150970ab2e8d8df9dc578e2 100644 --- a/docs/nmaas-applications/new-application.md +++ b/docs/nmaas-applications/new-application.md @@ -1,13 +1,13 @@ # Adding a new Application -Anyone can submit an application to be included to the NMaaS catalog, thus making it available to all users of the production instance. Each application should have at least one official maintainer who will regularly pull changes from the upstream project and provide updated Docker images and Helm charts. The source code for each Helm chart should be hosted in a separate Git repository. +Anyone can submit an application to be included to the nmaas catalog, thus making it available to all users of the production instance. Each application should have at least one official maintainer who will regularly pull changes from the upstream project and provide updated Docker images and Helm charts. The source code for each Helm chart should be hosted in a separate Git repository. A brief guide on how a new chart repository can be set up using the GitHub platform is presented below. Please note that we do not require the use of GitHub or mandate a specific code hosting service. Any platform that is publicly accessible would suffice. !!! note "Process Explanation" - Applying for an application to be added to the NMaaS catalog is a two-step process. First, the chart needs to be created, and then a brief proposal submitted to the NMaaS team via email. After reviewing the chart, the user who submitted it will be assigned a new role on the production instance of NMaaS (https://nmaas.eu) – <i><u>tool manager</u></i>, which allows uploading of new versions and parameter changes. + Applying for an application to be added to the nmaas catalog is a two-step process. First, the chart needs to be created, and then a brief proposal submitted to the nmaas team via email. After reviewing the chart, the user who submitted it will be assigned a new role on the production instance of nmaas (https://nmaas.eu) – <i><u>tool manager</u></i>, which allows uploading of new versions and parameter changes. ## Step 1: Create a new GitHub Repository @@ -258,7 +258,7 @@ You can find the generated link to your GitHub Pages website by navigating to Se ## Step 7: Generating a README File with Default Values for the Chart -Each chart submitted for addition to the NMaaS catalog must have a README file containing all of the parameters that can be altered during its deployment. Such a README file can either be created manually or automatically. Helm-docs is one such tool for automated generation of chart descriptions. +Each chart submitted for addition to the nmaas catalog must have a README file containing all of the parameters that can be altered during its deployment. Such a README file can either be created manually or automatically. Helm-docs is one such tool for automated generation of chart descriptions. - Download the latest release of helm-docs from the official Releases page: https://github.com/norwoodj/helm-docs/releases @@ -292,7 +292,7 @@ The workflow for releasing a new version of a chart is: - creating a new pull request to merge these changes to `master`. At this point the linting task will be executed. - merge the changes to the `master` branch. At this point the release task will be executed. -If you want to see your chart added to the NMaaS catalog please contact [nmaas-admin@lists.geant.org](mailto:nmaas-admin@lists.geant.org) with the following information: +If you want to see your chart added to the nmaas catalog please contact [nmaas-admin@lists.geant.org](mailto:nmaas-admin@lists.geant.org) with the following information: - URL to the upstream source-code repository of the proposed application - Brief description of its features diff --git a/docs/nmaas-applications/tutorials/booked.md b/docs/nmaas-applications/tutorials/booked.md index 1ef1adb38fbda16f197d7e67c32f7ef6b8637776..17917e3a7ffa6cac43ccdc1098f4ae12b5c8ff3c 100644 --- a/docs/nmaas-applications/tutorials/booked.md +++ b/docs/nmaas-applications/tutorials/booked.md @@ -11,7 +11,7 @@ A web-based calendar and resource scheduling system that allows administered man ## Default Credentials -As stated in the [Base tab](#base-tab) section, the admin username is the administrator's email address that is specified during the deployment process directly from the NMaaS web interface. The default password is simply `password`. Users are strongly encouraged to change the default password of their admin accounts after the initial login. +As stated in the [Base tab](#base-tab) section, the admin username is the administrator's email address that is specified during the deployment process directly from the nmaas web interface. The default password is simply `password`. Users are strongly encouraged to change the default password of their admin accounts after the initial login. ## Configuration wizard diff --git a/docs/nmaas-applications/tutorials/changedetectionio.md b/docs/nmaas-applications/tutorials/changedetectionio.md index 1dabf40398dc433f92fcfa9ac3ec627f4b1c17d2..d83137ea7be1c64c28b2244acf287ed4da2a7256 100644 --- a/docs/nmaas-applications/tutorials/changedetectionio.md +++ b/docs/nmaas-applications/tutorials/changedetectionio.md @@ -2,11 +2,11 @@ [ChangeDetection.io](https://github.com/dgtlmoon/changedetection.io) is an open-source tool for website change detection. It is capable of monitoring HTML and JSON files and can send various types of notifications when a change is detected. -Using XPath or CSS selectors it is also possible to only watch specific page elements. Interactive websites relying heavily on JavaScript can be crawled using a headless Chrome instance which is also deployed on NMaaS together with the base application. +Using XPath or CSS selectors it is also possible to only watch specific page elements. Interactive websites relying heavily on JavaScript can be crawled using a headless Chrome instance which is also deployed on nmaas together with the base application. ## Customizable Parameters -ChangeDetection.io does not have any parameters that need to be customized during the initial deployment on NMaaS. +ChangeDetection.io does not have any parameters that need to be customized during the initial deployment on nmaas. All configuration is done from the built-in configuration manager accessible once the application is deployed. @@ -36,7 +36,7 @@ All configuration is done from the built-in configuration manager accessible onc ChangeDetection.io has support for various notification providers, using the [Apprise library](https://github.com/caronc/apprise). Details about each supported notification provider are given on the [Apprise Wiki](https://github.com/caronc/apprise/wiki), as well as on the [ChangeDetection.io wiki](https://github.com/caronc/apprise/wiki) pages. -In terms of the managed NMaaS production instance, users can leverage the built-in mail sender, using the following configuration: +In terms of the managed nmaas production instance, users can leverage the built-in mail sender, using the following configuration: ``` mailto://nmaas.eu:587?smtp=nmaas-postfix.nmaas-system&from=changedetection.$domain-name@nmaas.eu&to=$dest-email diff --git a/docs/nmaas-applications/tutorials/gp4l-orchestrator.md b/docs/nmaas-applications/tutorials/gp4l-orchestrator.md index 23c3632eb6087b3ab084d0c9d666860679ac52e4..b72f2c47e5737dffe983369bd3594c1229743336 100644 --- a/docs/nmaas-applications/tutorials/gp4l-orchestrator.md +++ b/docs/nmaas-applications/tutorials/gp4l-orchestrator.md @@ -30,7 +30,7 @@ Configuration parameters to be provided by the user are explained in the list be - `Password for the Uptime Kuma web server` - password related to the defined username - `Password for the Uptime Kuma API` - password used to authenticate to the Uptime Kuma API - `Oxidized Git repository URL` - URL to the Git repository related to the Oxidized instance that is to be used -- `Email addresses to receive the generated repository access SSH public key` - once the Camunda orchestrator is setup and initialized it will generate a pair of ssh keys used to access the Oxidized Git repository. The public key of this pair will be sent to this email address and will then need to be copy pasted to the NMaaS user profile. (Note: check the junk folder) +- `Email addresses to receive the generated repository access SSH public key` - once the Camunda orchestrator is setup and initialized it will generate a pair of ssh keys used to access the Oxidized Git repository. The public key of this pair will be sent to this email address and will then need to be copy pasted to the nmaas user profile. (Note: check the junk folder) - `The name to use for all Git commits created by Camunda` - name under which all Git changes will be made - `The email to use for all Git commits created by Camunda` - email under which all Git changes will be made diff --git a/docs/nmaas-applications/tutorials/grafana.md b/docs/nmaas-applications/tutorials/grafana.md index 164078f62de03f3599c3f436ca58b64b39dd7731..463646d21d4373c94782ef663241d522bcdbca26 100644 --- a/docs/nmaas-applications/tutorials/grafana.md +++ b/docs/nmaas-applications/tutorials/grafana.md @@ -15,9 +15,9 @@ Configuration parameters to be provided by the user are explained in the subsect - `Grafana admin username` - Username to be used to access the Grafana user interface - `Grafana admin password` - Password to be used to access the Grafana user interface - `Connect to existing Prometheus instance` ***[Optional]*** - If selected, additional fields are displayed allowing to provide information about a Prometheus instance that should be added as a default data source in Grafana -- `NMaaS Prometheus instance` / `External Prometheus instance` - Switch between the type of Prometheus instance that should be used as the data source +- `nmaas Prometheus instance` / `External Prometheus instance` - Switch between the type of Prometheus instance that should be used as the data source - `Data source name` - The custom data source name that will be assigned to this Prometheus instance -- `Select Prometheus instance` *(if NMaaS Prometheus instance is selected)* - Pick list allowing to select an instance of Prometheus deployed and already running in the same domain as the Grafana being configured +- `Select Prometheus instance` *(if nmaas Prometheus instance is selected)* - Pick list allowing to select an instance of Prometheus deployed and already running in the same domain as the Grafana being configured - `Prometheus instance address` *(if External Prometheus instance is selected)* - URL of the standalone Prometheus instance to be used ### Additional tab diff --git a/docs/nmaas-applications/tutorials/icinga2.md b/docs/nmaas-applications/tutorials/icinga2.md index b717a862f51f058a90440b8b90e2bd465591a1b6..08f0dd22667deffdcbc4ffb1de29f2062fde9fcf 100644 --- a/docs/nmaas-applications/tutorials/icinga2.md +++ b/docs/nmaas-applications/tutorials/icinga2.md @@ -6,6 +6,6 @@ Icinga 2 is a monitoring system which checks the availability of your network re Scalable and extensible, Icinga can monitor large, complex environments across multiple locations. -Icinga 2 is the monitoring server and requires Icinga Web 2 on top in your Icinga Stack, which is already included as part of the NMaaS deployment. +Icinga 2 is the monitoring server and requires Icinga Web 2 on top in your Icinga Stack, which is already included as part of the nmaas deployment. The configuration can be easily managed with either the Icinga Director, config management tools or plain text within the Icinga DSL. \ No newline at end of file diff --git a/docs/nmaas-applications/tutorials/librenms.md b/docs/nmaas-applications/tutorials/librenms.md index 5b1cf07fdfd474ceb9347ea15f129c782118fadc..ae170aabde0cb5edff58c1e46c0ab19892e5a72e 100644 --- a/docs/nmaas-applications/tutorials/librenms.md +++ b/docs/nmaas-applications/tutorials/librenms.md @@ -8,11 +8,9 @@ LibreNMS is an auto-discovering PHP/MySQL/SNMP based network monitoring system w Configuration parameters to be provided by the user are divided into two tabs: *Base tab* and *Advanced tab*. -<!--  --> - <figure markdown> -  - <figcaption>NMaaS LibreNMS Application Wizard</figcaption> +  + <figcaption>nmaas LibreNMS Application Wizard</figcaption> </figure> ### Base Tab diff --git a/docs/nmaas-applications/tutorials/maildev.md b/docs/nmaas-applications/tutorials/maildev.md index ed97540c278bd504274a49c93e39dfe095bfb95d..bbc6ee62a618e88a213e2dda4447f421d5ae4057 100644 --- a/docs/nmaas-applications/tutorials/maildev.md +++ b/docs/nmaas-applications/tutorials/maildev.md @@ -6,11 +6,11 @@ MailDev is a simple application that can be used during the development process MailDev provides a web interface where all "sent" emails can be previewed. MailDev itself does not send the emails to their final destination, instead just logs them so that they are visible on the web interface and discards them. This makes it possible to use MailDev for testing purposes, without having to worry about rate limits, deliverability, or spam. -## Deploying MailDev on NMaaS +## Deploying MailDev on nmaas -The MailDev application on NMaaS is primarily aimed at users of the virtual lab use-case. For production applications instantiated on the managed instance of NMaaS, it is possible to use the NMaaS email server, and this is the case by default for most tools already in the catalog. +The MailDev application on nmaas is primarily aimed at users of the virtual lab use-case. For production applications instantiated on the managed instance of nmaas, it is possible to use the nmaas email server, and this is the case by default for most tools already in the catalog. -To deploy and configure MailDev on NMaaS, the following steps need to be performed: +To deploy and configure MailDev on nmaas, the following steps need to be performed: - Subscribe to the application from the Application list. - Navigate to the Subscriptions page and initiate the deployment of a new MailDev instnace, by entering the name and desired version. @@ -20,7 +20,7 @@ To deploy and configure MailDev on NMaaS, the following steps need to be perform <figcaption>Fig. 1: New MailDev Instance</figcaption> </figure> -- Use the deployment wizard to further customize your new MailDev instance. The current version of the deployment wizard allows the set up of a basic HTTP authentication to the MailDev web interface. This might be useful if multiple users have access to your NMaaS domain. +- Use the deployment wizard to further customize your new MailDev instance. The current version of the deployment wizard allows the set up of a basic HTTP authentication to the MailDev web interface. This might be useful if multiple users have access to your nmaas domain. <figure markdown> { width="350" } @@ -36,7 +36,7 @@ To deploy and configure MailDev on NMaaS, the following steps need to be perform Once deployed, the MailDev web interface becomes available. At this point, any existing application which supports SMTP based notifications can be configured to use the MailDev SMTP implementation with the following settings: -- SMTP server address: (the correct hostname is shown in the access modes modal on NMaaS) +- SMTP server address: (the correct hostname is shown in the access modes modal on nmaas) - SMTP server port: 1025 - SMTP Username: / - SMTP Password: / diff --git a/docs/nmaas-applications/tutorials/oxidized.md b/docs/nmaas-applications/tutorials/oxidized.md index 2569fd76bf103dc9d0ed03031321d1697d73c3e4..cb623684af6ddb97e2402f50275e8c5d293846c8 100644 --- a/docs/nmaas-applications/tutorials/oxidized.md +++ b/docs/nmaas-applications/tutorials/oxidized.md @@ -26,7 +26,7 @@ Multiple devices can be configured by using the `Add device` button. ### Configuration Update -Oxidized allows for updating tools configuration during runtime. User should follow the steps described on the [NMaaS Tool Configuration Process](../general-app-deployment.md#nmaas-tool-configuration-process) page. +Oxidized allows for updating tools configuration during runtime. User should follow the steps described on the [nmaas Tool Configuration Process](../general-app-deployment.md#nmaas-tool-configuration-process) page. Inside the repository two files are being created by default, namely `config` and `router.db`, and are placed in the `base` directory. diff --git a/docs/nmaas-applications/tutorials/spa.md b/docs/nmaas-applications/tutorials/spa.md index b46429a3a2d837a928d304036f395e7d888ce181..50f5d7638c53e356438990c9361595fa04ef11c7 100644 --- a/docs/nmaas-applications/tutorials/spa.md +++ b/docs/nmaas-applications/tutorials/spa.md @@ -6,7 +6,7 @@ The Service Provider Architecture (SPA) is a service management digital platform providing the general processes and components necessary to manage the CSP services via a user-friendly web graphical user interface (Self-Service Portal). -The platform in NMaaS has been prepared to manage E-Line service (L2 end-to-end connectivity) implemented by the OpenNSA application with a test default configuration and virtual simplified network topology. Users can familiarize with the SPA without the need of setting up the platform from the scratch. +The platform in nmaas has been prepared to manage E-Line service (L2 end-to-end connectivity) implemented by the OpenNSA application with a test default configuration and virtual simplified network topology. Users can familiarize with the SPA without the need of setting up the platform from the scratch. Just log in to the portal and start creating new circuits in a simple network to see how it works. diff --git a/docs/nmaas-applications/tutorials/uptime-kuma.md b/docs/nmaas-applications/tutorials/uptime-kuma.md index b1e823a9d4994b8da6174c43b37fac7b61c9ee67..3c7c2b4cb4dd62bb6d7c9889213c007059f42b94 100644 --- a/docs/nmaas-applications/tutorials/uptime-kuma.md +++ b/docs/nmaas-applications/tutorials/uptime-kuma.md @@ -13,9 +13,9 @@ - various other application specific monitors for PostgreSQL, MariaDB, MongoDB, etc... - design and create status pages -## Uptime Kuma on NMaaS +## Uptime Kuma on nmaas -Uptime Kuma on NMaaS is fully supported in two flavors: +Uptime Kuma on nmaas is fully supported in two flavors: - standalone flavor, identical with the upstream release, without any modifications. - extended flavor which also supports API access using a [third-party API extension](https://github.com/MedAziz11/Uptime-Kuma-Web-API). @@ -24,7 +24,7 @@ Refer to the sections below for more details regarding deployment options for th ### Deploiying the Standalone Version of Uptime Kuma -As with any other application available in the NMaaS catalog, the deployment process for the standalone version is: +As with any other application available in the nmaas catalog, the deployment process for the standalone version is: 1. Subscribe your domain to the Uptime Kuma application from the `Applications` page. 2. Deploy a new instance of Uptime Kuma, providing a unique name for it. @@ -34,7 +34,7 @@ As with any other application available in the NMaaS catalog, the deployment pro ### Deploying Uptime Kuma together with an API Server -NMaaS also offers an extended flavor of Uptime Kuma, one that comes collocated with the open-source API server implementation by [MedAziz11/Uptime-Kuma-Web-API](https://github.com/MedAziz11/Uptime-Kuma-Web-API). The deployment process for this flavor, differs somewhat from the standalone version, taking into account the additional features. The deployment steps are: +nmaas also offers an extended flavor of Uptime Kuma, one that comes collocated with the open-source API server implementation by [MedAziz11/Uptime-Kuma-Web-API](https://github.com/MedAziz11/Uptime-Kuma-Web-API). The deployment process for this flavor, differs somewhat from the standalone version, taking into account the additional features. The deployment steps are: 1. Subscribe your domain to the Uptime Kuma application from the `Applications` page. 2. Deploy a new instance of Uptime Kuma, providing a unique name for it. @@ -45,7 +45,7 @@ NMaaS also offers an extended flavor of Uptime Kuma, one that comes collocated w <figcaption>Fig. 1: Uptime Kuma Deployment Wizard</figcaption> </figure> -4. Enter the username and password for the default Uptime Kuma user. NMaaS will automatically initialize a new user with the specified credentials, and the first run page will be skipped once the application is deployed. The user will be able to directly login. +4. Enter the username and password for the default Uptime Kuma user. nmaas will automatically initialize a new user with the specified credentials, and the first run page will be skipped once the application is deployed. The user will be able to directly login. 5. Enter the password for the API user. The API user is different from the Uptime Kuma user. The default username for the API user is `admin`. This username cannot be changed at the moment. 6. Finish the deployment process and access the Uptime Kuma web interface and the API's OpenAPI documentation. @@ -65,4 +65,4 @@ NMaaS also offers an extended flavor of Uptime Kuma, one that comes collocated w **The default username for the API is always `admin`.** !!! danger - Changing the user's password from the Uptime Kuma web interface after the application has been deployed will make the API addon nonfunctional. Contact the NMaaS team in case a password change is necessary. \ No newline at end of file + Changing the user's password from the Uptime Kuma web interface after the application has been deployed will make the API addon nonfunctional. Contact the nmaas team in case a password change is necessary. \ No newline at end of file diff --git a/docs/nmaas-applications/tutorials/zabbix.md b/docs/nmaas-applications/tutorials/zabbix.md index 57fd862afe088fb969c170c8cd2db5c3c3a6900c..2fb764bc862474f01f4fd8bdc28de0ee81248b01 100644 --- a/docs/nmaas-applications/tutorials/zabbix.md +++ b/docs/nmaas-applications/tutorials/zabbix.md @@ -4,6 +4,6 @@ Zabbix is a mature and effortless enterprise-class open source monitoring solution for network monitoring and application monitoring of millions of metrics. -The Zabbix application included in the NMaaS catalog uses TimescaleDB for better performance. +The Zabbix application included in the nmaas catalog uses TimescaleDB for better performance. After deployment, use the default `Admin/zabbix` credentials to login. \ No newline at end of file