diff --git a/api/README.md b/api/README.md index fe04f066b..fbd6c1a07 100644 --- a/api/README.md +++ b/api/README.md @@ -6,9 +6,15 @@ This project provides a RESTful API for accessing Cacti monitoring data using th The API exposes endpoints to retrieve information about hosts, host templates, poller status, graph lists, Cacti status, boost status, database connectivity, and plugin thresholds. All responses are in JSON format. -THIS IS NOT PROD READY! +**This API is not production ready.** -To run the API php -S 127.0.0.1:8080 -t public ( Which for Prod will be replaced with a WSGI server) +To run the API for development: + +```bash +php -S 127.0.0.1:8080 -t public public/index.php +``` + +For production, this should be served by a proper web server (Apache, Nginx, etc.). ## API Versioning @@ -52,7 +58,7 @@ The API uses URL path versioning. All endpoints are prefixed with a version numb Checks database connectivity. - `GET /v1/status/cacti_db_status` - Returns some metrics of the Main cacti DB + Returns metrics for the main Cacti database. #### Plugin Endpoints - `GET /v1/plugin/thold/thresholds` @@ -69,7 +75,7 @@ The API uses URL path versioning. All endpoints are prefixed with a version numb ## Requirements -- PHP 7.4 or higher +- PHP 8.1 or higher - Composer - Cacti database and configuration diff --git a/locales/README.md b/locales/README.md index cadfff357..436e24c0a 100644 --- a/locales/README.md +++ b/locales/README.md @@ -18,7 +18,7 @@ machine readable versions of the language translation per country and language. ## Management Process When making a pull request, if you are modifying human readable strings, it's -important that the user modifying those strings to include an updated **cacti.pot** +important that the user modifying those strings include an updated **cacti.pot** file in their pull requests. To update the **cacti.pot** file, you would simply follow the directions below: @@ -32,7 +32,7 @@ This script will perform the following steps: - Update your copy of the various language translation files (*.po) per country and language - Update your copy of the various binary translation files (*.mo) per country and language -The the **build_gettext.sh** script updates both the *.po and *.mo files, those are not important +While the **build_gettext.sh** script updates both the *.po and *.mo files, those are not important for your pull requests as Weblate updates those files automatically as soon as it detects the change in the **cacti.pot** file from your pull request. @@ -51,10 +51,10 @@ into the Cacti GitHub repository, which will be a signal to the team. Once we s translation, we may have a few additional steps that need to be required on the Cacti site. Someone from the Cacti Development team will reach out to you with those instructions. -Once the Cacti language translation file has been properly on boarded, you can use either +Once the Cacti language translation file has been properly onboarded, you can use either PO Edit or the Weblate sites to make edits to the file. We find that if you are translating -a new language, you should first let the Cacti Group do an automatic translation, of if you -want to contribute to PO Edit Professionals development, you can pay for a license to +a new language, you should first let The Cacti Group do an automatic translation, or, if you +want to contribute to PO Edit Professional's development, you can pay for a license to facilitate a first pass language translation. One of the key benefits of using Weblate, is that if you have created additional language diff --git a/service/README.md b/service/README.md index 77d643e77..e6fda335b 100644 --- a/service/README.md +++ b/service/README.md @@ -6,11 +6,11 @@ ### Background -PHP has matured over the years, and in the year 2020, it is now possible to -create reliable services leveraging it. Cacti for years used crontab as a -launcher primarily due to the issues we had experienced in the early days of -PHP 4.2 with constant memory leaks with the core PHP and the various PHP -modules that were in use. However, times are changing. +PHP has matured over the years, and it is now possible to create reliable +services leveraging it. Cacti for years used crontab as a launcher primarily +due to the issues we had experienced in the early days of PHP 4.2 with constant +memory leaks with the core PHP and the various PHP modules that were in use. +However, times are changing. With the advent of technologies such as MariaDB Galera, keepalived, haproxy, and database session management for fault tolerant web server and @@ -19,8 +19,8 @@ RRDfile and web site content fault tolerance, the idea of a fully distributed highly available Cacti is now possible. Add to that, the concept of Remote Data Collectors for network resiliency, -and Cacti has fully entering into what I refer to as 'enterprise' class in -it's stability and reliability. +and Cacti has fully entered into what I refer to as 'enterprise' class in +its stability and reliability. However, to more easily support keepalived, we need to move away from the crontab based setup Cacti has used for nearly 20 years. Long live Crontab! @@ -35,10 +35,10 @@ There are only a few steps. For this service here they are. 2. Modify the file to point to the real path of the cactid.php file located in the cacti base directory by default 3. Modify the file to use the user and group that your Cacti is installed - with, on RedHat variants, it usually: apache:apache, for Debian variants, - its generally www-run:www + with, on RedHat variants, it is usually: apache:apache, for Debian variants, + it is generally www-data:www-data 4. Create the file /etc/sysconfig/cactid, even though it's not used today, - we'll keep it there for as a future path to over write certain settings + we'll keep it there as a future path to overwrite certain settings 5. Install the service using 'systemctl enable cactid' 6. Reload systemd using 'systemctl daemon-reload' 7. Comment out the cacti crontab file or simply remove the /etc/cron.d/cacti