zydronium/getnamingo-registry
1
0
Fork 0
mirror of https://github.com/getnamingo/registry.git synced 2025-08-05 01:01:30 +02:00
Code Issues Projects Releases Packages Wiki Activity

Documentation update, fixed #158

Browse source
This commit is contained in:
Pinga 2024-09-19 19:36:58 +03:00
parent 9a522b277c
commit 5aebd772b5
4 changed files with 640 additions and 579 deletions
Download patch file Download diff file Expand all files Collapse all files

6
README.md
View file

@ -72,7 +72,7 @@ Our documentation provides comprehensive guidance on installation, configuration
### Installation and Update Instructions
#### Automated Install
#### Installer
To begin, simply copy the command below and paste it into your server terminal. This installation process is optimized for a fresh VPS running Ubuntu 22.04/24.04 or Debian 12.
@ -92,9 +92,9 @@ precedence ::ffff:0:0/96 100
In the `config.php` files of WHOIS/DAS components make sure you replace `::` with `false` or for EPP - with `0.0.0.0`
#### Manual Installation Steps
#### Legacy Installation Guide
For detailed installation steps, please refer to [install.md](docs/install.md).
For those who prefer a more hands-on approach or need detailed installation instructions, refer to the [Legacy Installation Guide](docs/install.md). However, we recommend using the installer for a more streamlined experience.
#### Update Steps

680
docs/configuration.md
View file

@ -1,8 +1,620 @@
# Configuration Guide
This document provides detailed instructions on configuring Namingo, the domain registry management tool, after installation. Each configuration file and its respective settings are explained for easy setup and customization.
This document provides instructions for configuring Namingo, the domain registry management tool, after installation. It covers configuring the system, adding additional components, and customizing various configuration files for optimal setup.
## Automation Configuration (`/opt/registry/automation/config.php`)
## 1. Post-Installation Configuration
This section provides instructions for configuring your system after installing Namingo, including setting up additional components and customizing configuration files.
### 1.1. Launching WHOIS, RDAP, and DAS Servers
To start the WHOIS, RDAP, and DAS servers, use the following commands:
```bash
systemctl start whois
systemctl start rdap
systemctl start das
```
Ensure each service is properly configured before starting. You can verify the status of each server with:
```bash
systemctl status whois
systemctl status rdap
systemctl status das
```
### 1.2. Launching EPP Server
Before launching the EPP server, edit `/opt/registry/epp/config.php` to set the paths to your certificates and configure other options as needed.
To create test certificates (`cert.pem` and `key.pem`), execute the following commands:
```bash
cd /opt/registry/epp/
openssl genrsa -out key.pem 2048
openssl req -new -x509 -key key.pem -out cert.pem -days 365
```
Once configured, you can launch the EPP server in the same way as the others:
```bash
systemctl start epp
```
### 1.3. Additional Control Panel Setup
#### 1.3.1. Install Optional Dependencies
To enhance the functionality of your control panel, install optional dependencies by executing the following command:
```bash
cd /var/www/cp
composer require phpmailer/phpmailer
```
#### 1.3.2. Setting Up Redis Session Storage
To utilize Redis for session storage, you need to install the necessary packages and configure your environment accordingly. Follow these steps to set up Redis session storage:
```bash
cd /var/www/cp
composer require predis/predis pinga/session-redis
```
After installation, log out of your application if you are currently logged in. This ensures that the session starts afresh with the new configuration.
Clear your browser cookies related to the application. This step is crucial as it removes any existing session cookies that were set using the previous session storage mechanism.
Upon your next login, Redis will be used for storing session data. The new sessions will be created and managed through Redis, providing a more scalable and efficient session management system.
**Note**: Ensure that your Redis server is properly configured and running before proceeding with these steps. If in doubt, check with:
```bash
systemctl status redis-server
```
### 1.4. Setting Up the Automation System
Follow these steps to configure the automation system for your registry:
#### 1.4.1. Configuration
Move to the automation directory with the following command:
```bash
cd /opt/registry/automation
```
Open `config.php` and adjust all necessary settings to suit your system's requirements. Make sure to review and fine-tune each option for optimal performance.
#### 1.4.2. Install Optional Dependencies
Execute one of the following commands to install the optional dependencies:
```bash
composer require utopia-php/messaging
```
or
```bash
composer require phpmailer/phpmailer
```
This command will install one of the packages which are essential for the message broker script to function correctly.
#### 1.4.3. Configuring the Message Broker
You can easily configure the message broker for email delivery in ```config.php```. It is compatible with SendGrid, Mailgun API, and PHPMailer for those opting to use their own SMTP server. All necessary settings are conveniently located under the mailer_ lines within the file.
For establishing your own mail server, Mox, available at [GitHub](https://github.com/mjl-/mox), provides a comprehensive solution. Install Mox following its GitHub instructions, then enter the required details in the ```config.php``` file.
To run the Message Broker, execute the following commands:
```bash
/usr/bin/php /opt/registry/automation/msg_producer.php &
/usr/bin/php /opt/registry/automation/msg_worker.php &
```
This will start the system and place it in the background, allowing it to run independently of your current terminal session.
#### 1.4.4. Setting Up an Audit Trail Database for Namingo
To create an audit trail database for Namingo, start by editing the configuration file located at `/opt/registry/automation/audit.json` with the correct database details. This includes specifying the database connection parameters such as host, username, and password. Once your configuration is set up, run the command:
```bash
/opt/registry/automation/vendor/bin/audit -v audit /opt/registry/automation/audit.json
```
This will initialize and configure the audit trail functionality. This process ensures that all necessary tables and structures are set up in the registryAudit database, enabling comprehensive auditing of Namingo's operations.
**Currently, the audit trail setup for Namingo is supported only with MySQL or MariaDB databases. If you're using PostgreSQL, you'll need to utilize an external tool for audit logging, such as [pgAudit](https://minervadb.com/index.php/pgaudit-open-source-postgresql-audit-logging/), which provides detailed audit logging capabilities tailored for PostgreSQL environments.**
#### 1.4.5. Setup Backup
To ensure the safety and availability of your data in Namingo, it's crucial to set up and verify automated backups. Begin by editing the ```backup.json``` file in the automation directory, where you'll input your database details. Ensure that the details for the database are accurately entered in two specified locations within the ```backup.json``` file.
Additionally, check that the cronjob for PHPBU is correctly scheduled on your server, as this automates the backup process. You can verify this by reviewing your server's cronjob list. These steps are vital to maintain regular, secure backups of your system, safeguarding against data loss and ensuring business continuity.
#### 1.4.6. RDE (Registry data escrow) configuration
**1.4.6.1. Generate the Key Pair**: Create a configuration file, say key-config, with the following content:
```yaml
%echo Generating a default key
Key-Type: RSA
Key-Length: 2048
Subkey-Type: RSA
Subkey-Length: 2048
Name-Real: Your Name
Name-Comment: Your Comment
Name-Email: your.email@example.com
Expire-Date: 0
%no-protection
%commit
%echo done
```
Replace "Your Name", "Your Comment", and "your.email@example.com" with your details.
Use the following command to generate the key:
```bash
gpg2 --batch --generate-key key-config
```
Your GPG key pair will now be generated.
**1.4.6.2. Exporting Your Keys**:
Public key:
```bash
gpg2 --armor --export your.email@example.com > publickey.asc
```
Replace `your-email@example.com` with the email address you used when generating the key.
Private key:
```bash
gpg2 --armor --export-secret-keys your.email@example.com > privatekey.asc
```
**1.4.6.3. Secure Your Private Key**: Always keep your private key secure. Do not share it. If someone gains access to your private key, they can impersonate you in cryptographic operations.
**1.4.6.4. Use in RDE deposit generation**: Please send the exported `publickey.asc` to your RDE provider, and also place the path to `privatekey.asc` in the escrow.php system as required.
#### 1.4.7. Running the Automation System
Once you have successfully configured all automation scripts, you are ready to initiate the automation system. Please review ```/opt/registry/automation/cron.php``` and enable all services if you are running a gTLD. Then proceed by adding the following cron job to the system crontab using ```crontab -e```:
```bash
* * * * * /usr/bin/php /opt/registry/automation/cron.php 1>> /dev/null 2>&1
```
## 2. Recommended Components and Integrations
This section outlines recommended components to enhance the functionality and reliability of your Namingo setup. These include essential services like DNS servers, monitoring tools, and other integrations that can help maintain a robust registry environment.
### 2.1. Setup Hidden Master DNS with BIND
Although Namingo is equipped with BIND by default for this purpose, you can opt for NSD, or Knot DNS if you are more comfortable with those systems.
#### Install BIND9 and its utilities with
```bash
apt install bind9 bind9-utils bind9-doc
```
#### Generate a TSIG key
Generate a TSIG key which will be used to authenticate DNS updates between the master and slave servers. **Note: replace ```test``` with your TLD.**
```bash
cd /etc/bind
tsig-keygen -a HMAC-SHA256 test.key
```
The output will be in the format that can be directly included in your BIND configuration files. It looks something like this:
```bash
key "test.key" {
algorithm hmac-sha256;
secret "base64-encoded-secret==";
};
```
Copy this output for use in the configuration files of both the master and slave DNS servers. (```/etc/bind/named.conf.local```)
#### Configure the Named Configuration File (Please Choose One)
1. Without DNSSEC:
Edit the named.conf.local file:
```bash
nano /etc/bind/named.conf.local
```
Add the following zone definition:
```bash
zone "test." {
type master;
file "/var/lib/bind/test.zone";
allow-transfer { key "test.key"; };
also-notify { <slave-server-IP>; };
};
```
Replace ```<slave-server-IP>``` with the actual IP address of your slave server. Replace ```test``` with your TLD.
Use rndc to reload BIND:
```bash
systemctl restart bind9
```
Configure the `Zone Writer` in Registry Automation and run it manually the first time.
```bash
php /opt/registry/automation/write-zone.php
```
2. Using DNSSEC with BIND9:
Edit the named.conf.local file:
```bash
nano /etc/bind/named.conf.local
```
Add the following DNSSEC policy:
```bash
dnssec-policy "namingo-policy" {
keys {
ksk lifetime P3M algorithm ed25519;
zsk lifetime P1M algorithm ed25519;
};
max-zone-ttl 86400;
dnskey-ttl 3600;
zone-propagation-delay 3600;
parent-propagation-delay 7200;
parent-ds-ttl 86400;
};
```
Add the following zone definition:
```bash
zone "test." {
type master;
file "/var/lib/bind/test.zone";
dnssec-policy "namingo-policy";
key-directory "/var/lib/bind";
inline-signing yes;
allow-transfer { key "test.key"; };
also-notify { <slave-server-IP>; };
};
```
Replace ```<slave-server-IP>``` with the actual IP address of your slave server. Replace ```test``` with your TLD.
Initially, you will need to generate the DNSSEC ZSK and KSK manually:
```bash
dnssec-keygen -a Ed25519 -n ZONE test.
dnssec-keygen -a Ed25519 -n ZONE -f KSK test.
```
After generating the keys, place them in ```/var/lib/bind```. Run ```dnssec-dsfromkey Ktest.EXAMPLE.key``` on the KSK key you just generated, and the DS record must be submitted to IANA once setup is complete.
Use rndc to tell BIND to load and use the new keys:
```bash
systemctl restart bind9
rndc loadkeys test.
```
Configure the `Zone Writer` in Registry Automation and run it manually the first time.
```bash
php /opt/registry/automation/write-zone.php
```
3. Using DNSSEC with OpenDNSSEC:
Edit the named.conf.local file:
```bash
nano /etc/bind/named.conf.local
```
Add the following zone definition:
```bash
zone "test." {
type master;
file "/var/lib/bind/test.zone.signed";
allow-transfer { key "test.key"; };
also-notify { <slave-server-IP>; };
};
```
Replace ```<slave-server-IP>``` with the actual IP address of your slave server. Replace ```test``` with your TLD.
Install OpenDNSSEC:
```bash
apt install opendnssec opendnssec-enforcer-sqlite3 opendnssec-signer softhsm2
```
Update files in `/etc/opendnssec` to match your registry policy. As minimum, please enable at least Signer Threads in `/etc/opendnssec/conf.xml`, but we recommend to fully review [all the files](https://wiki.opendnssec.org/configuration/confxml/). Then run the following commands:
```bash
softhsm2-util --init-token --slot 0 --label OpenDNSSEC --pin 1234 --so-pin 1234
ods-enforcer-db-setup
rm /etc/opendnssec/prevent-startup
ods-control start
ods-enforcer policy import
ods-enforcer zone add -z test -p default -i /var/lib/bind/test.zone
```
Use rndc to reload BIND:
```bash
systemctl restart bind9
```
Configure the `Zone Writer` in Registry Automation and run it manually the first time.
```bash
php /opt/registry/automation/write-zone.php
```
#### Check BIND9 Configuration
```bash
named-checkconf
named-checkzone test /var/lib/bind/test.zone
```
#### Restart BIND9 Service
```bash
systemctl restart bind9
```
#### Verify Zone Loading
Check the BIND9 logs to ensure that the .test zone is loaded without errors:
```bash
grep named /var/log/syslog
```
### 2.2. Regular DNS Server Setup
Before editing the configuration files, you need to copy the TSIG key from your hidden master server. The TSIG key configuration should look like this:
```bash
key "test.key" {
algorithm hmac-sha256;
secret "base64-encoded-secret==";
};
```
#### Installation of BIND9
```bash
apt update
apt install bind9 bind9-utils bind9-doc
```
#### Add the TSIG key to the BIND Configuration
Create a directory to store zone files:
```bash
mkdir /var/cache/bind/zones
```
Edit the `named.conf.local` file:
```bash
nano /etc/bind/named.conf.local
```
First, define the TSIG key at the top of the file:
```bash
key "test.key" {
algorithm hmac-sha256;
secret "base64-encoded-secret=="; // Replace with your actual base64-encoded key
};
```
Then, add the slave zone configuration:
```bash
zone "test." {
type slave;
file "/var/cache/bind/zones/test.zone";
masters { 192.0.2.1 key "test.key"; }; // IP of the hidden master and TSIG key reference
allow-query { any; }; // Allow queries from all IPs
allow-transfer { none; }; // Disable zone transfers (AXFR) to others
};
```
Make sure to replace `192.0.2.1` with the IP address of your hidden master server and `base64-encoded-secret==` with the actual secret from your TSIG key.
#### Adjusting Permissions and Ownership
Ensure BIND has permission to write to the zone file and that the files are owned by the BIND user:
```bash
chown bind:bind /var/cache/bind/zones
chmod 755 /var/cache/bind/zones
```
#### Restart BIND9 Service
After making these changes, restart the BIND9 service to apply them:
```bash
systemctl restart bind9
```
#### Verify Configuration and Zone Transfer
```bash
named-checkconf
grep 'transfer of "test."' /var/log/syslog
```
### 2.3. Setup Monitoring
For effective monitoring of your registry system, we highly recommend utilizing Prometheus.
```bash
wget https://github.com/prometheus/prometheus/releases/download/v2.48.1/prometheus-2.48.1.linux-amd64.tar.gz
tar xvfz prometheus-2.48.1.linux-amd64.tar.gz
cp prometheus-2.48.1.linux-amd64/prometheus /usr/local/bin/
cp prometheus-2.48.1.linux-amd64/promtool /usr/local/bin/
useradd --no-create-home --shell /bin/false prometheus
mkdir /etc/prometheus
mkdir /var/lib/prometheus
cp -r prometheus-2.48.1.linux-amd64/consoles /etc/prometheus
cp -r prometheus-2.48.1.linux-amd64/console_libraries /etc/prometheus
chown -R prometheus:prometheus /etc/prometheus
chown -R prometheus:prometheus /var/lib/prometheus
```
Place the following in the ```/etc/prometheus/prometheus.yml``` and customize as needed:
```
# Global settings and defaults.
global:
scrape_interval: 15s # By default, scrape targets every 15 seconds.
evaluation_interval: 15s # Evaluate rules every 15 seconds.
# Alertmanager configuration (commented out by default).
# alerting:
# alertmanagers:
# - static_configs:
# - targets:
# - localhost:9093
# Load and evaluate rules in this file.
# rule_files:
# - "first_rules.yml"
# - "second_rules.yml"
# Scrape configuration for running Prometheus on the same machine.
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: 'prometheus'
# metrics_path defaults to '/metrics'
# scheme defaults to 'http'.
static_configs:
- targets: ['localhost:9090']
# Example job for scraping an HTTP service.
- job_name: 'http_service'
static_configs:
- targets: ['<your_http_service>:80']
# Example job for scraping an HTTPS service.
- job_name: 'https_service'
static_configs:
- targets: ['<your_https_service>:443']
# Example job for scraping a DNS server.
- job_name: 'dns_monitoring'
static_configs:
- targets: ['<your_dns_server>:53']
# Add additional jobs as needed for your services.
```
Run the monitoring tool using:
```bash
prometheus --config.file=/etc/prometheus/prometheus.yml
```
The tool will be available at ```http://<your_server_ip>:9090```
### 2.4. Recommended Help Desk Solution
If you're in need of an effective help desk solution to complement your experience with Namingo, we recommend considering [FreeScout](https://freescout.net/), an AGPL-3.0 licensed, free and open-source software. FreeScout is known for its user-friendly interface and robust features, making it an excellent choice for managing customer queries and support tickets.
#### Please Note:
- FreeScout is an independent software and is not a part of Namingo. It is licensed under the AGPL-3.0, which is different from Namingo's MIT license.
- The recommendation to use FreeScout is entirely optional and for the convenience of Namingo users. Namingo functions independently of FreeScout and does not require FreeScout for its operation.
- Ensure to comply with the AGPL-3.0 license terms if you choose to use FreeScout alongside Namingo.
### 2.5. Adminer Security settings
To enhance the security of your Adminer installation, we recommend the following settings for Caddy, Apache2, and Nginx:
1. **Rename Adminer File:** Change `adminer.php` to `dbtool.php` to make it less predictable.
2. **Restrict Access by IP:** Only allow access from specific IP addresses.
Below are example configurations for each web server:
#### Caddy
```bash
# Adminer Configuration
route /dbtool.php* {
root * /usr/share/adminer
php_fastcgi unix//run/php/php8.2-fpm.sock
# Define the allowed IP address
@allowed {
remote_ip your.ip.address.here
}
# Route for allowed IP addresses
handle @allowed {
file_server
}
# Respond with 403 for any IP address not allowed
respond "Access Denied" 403
}
```
#### Apache .htaccess
```bash
<Files "dbtool.php">
Order Deny,Allow
Deny from all
Allow from your.ip.address.here
</Files>
```
#### Nginx
```bash
location /dbtool.php {
allow your.ip.address.here;
deny all;
}
```
## 3. In-Depth Configuration File Overview
In this section, we provide a detailed overview of each configuration file used in the Namingo domain registry platform. Understanding these files is essential for customizing and optimizing your system according to your specific needs. We will walk you through the purpose of each file, key settings, and recommended configurations to ensure smooth operation and integration with other components of your setup.
### Automation Configuration (`/opt/registry/automation/config.php`)
This configuration file is essential for setting up the automation scripts for the registry tool.
@ -85,13 +697,13 @@ return [
// LORDN Configuration
'lordn_user' => 'your_username', // Username for LORDN
'lordn_pass' => 'your_password', // Password for LORDN
// Minimum Data Set
'minimum_data' => false, // Set to true to enable minimum data set support
];
```
## Control Panel Configuration (`/var/www/cp/.env`)
### Control Panel Configuration (`/var/www/cp/.env`)
This file configures the environment for the control panel of Namingo.
@ -138,7 +750,7 @@ NOW_API_KEY='now-api-key'
TEST_TLDS=.test,.com.test
```
## DAS Server Configuration (`/opt/registry/das/config.php`)
### DAS Server Configuration (`/opt/registry/das/config.php`)
Configurations for the Domain Availability Service (DAS) server.
@ -160,7 +772,7 @@ return [
];
```
## EPP Server Configuration (`/opt/registry/epp/config.php`)
### EPP Server Configuration (`/opt/registry/epp/config.php`)
Settings for the Extensible Provisioning Protocol (EPP) server.
@ -189,7 +801,7 @@ return [
];
```
## RDAP Server Configuration (`/opt/registry/rdap/config.php`)
### RDAP Server Configuration (`/opt/registry/rdap/config.php`)
Configuration for the Registration Data Access Protocol (RDAP) server.
@ -212,7 +824,7 @@ return [
];
```
## WHOIS Server Configuration (`/opt/registry/whois/port43/config.php`)
### WHOIS Server Configuration (`/opt/registry/whois/port43/config.php`)
Settings for the WHOIS server running on port 43.
@ -237,58 +849,6 @@ return [
];
```
## Adminer Security settings
To enhance the security of your Adminer installation, we recommend the following settings for Caddy, Apache2, and Nginx:
1. **Rename Adminer File:** Change `adminer.php` to `dbtool.php` to make it less predictable.
2. **Restrict Access by IP:** Only allow access from specific IP addresses.
Below are example configurations for each web server:
### Caddy
```bash
# Adminer Configuration
route /dbtool.php* {
root * /usr/share/adminer
php_fastcgi unix//run/php/php8.2-fpm.sock
# Define the allowed IP address
@allowed {
remote_ip your.ip.address.here
}
# Route for allowed IP addresses
handle @allowed {
file_server
}
# Respond with 403 for any IP address not allowed
respond "Access Denied" 403
}
```
### Apache .htaccess
```bash
<Files "dbtool.php">
Order Deny,Allow
Deny from all
Allow from your.ip.address.here
</Files>
```
### Nginx
```bash
location /dbtool.php {
allow your.ip.address.here;
deny all;
}
```
In conclusion, this detailed configuration guide aims to streamline the setup process of the Namingo system for users of all expertise levels. The guide meticulously details each configuration file, providing clear explanations and guidance for customization to suit your specific needs. This approach ensures that you can configure Namingo with confidence, optimizing it for your registry management requirements. We are committed to making the configuration process as straightforward as possible, and we welcome any questions or requests for further assistance. Your successful deployment and efficient management of Namingo is our top priority.
After finalizing the configuration of Namingo, the next step is to consult the [Initial Operation Guide](iog.md). This guide provides comprehensive details on configuring your registry, adding registrars, and much more, to ensure a smooth start with your system.

513
docs/install.md
View file

@ -1,12 +1,8 @@
# Installation
# Installation (Deprecated)
Welcome to the Installation Guide for Namingo domain registry platform. For those who prefer a streamlined setup, an automated installation process is available at [https://namingo.org](https://namingo.org). We highly recommend utilizing this option for a hassle-free and efficient installation experience.
Welcome to the Installation Guide for the Namingo domain registry platform. Note: The manual installation process is now deprecated. We highly recommend using the automated installer available at [https://namingo.org](https://namingo.org) for a streamlined and hassle-free setup experience.
As you follow along with this document, it's important to also review the [Configuration Guide](configuration.md). This guide will provide you with detailed information on how to configure various components of Namingo, ensuring that your system is tailored to meet your specific requirements. Familiarizing yourself with these configuration steps during installation will help in setting up Namingo for optimal performance and functionality.
Once you have completed the installation process, we encourage you to proceed to the [Initial Operation Guide](iog.md) for detailed instructions on how to configure your registry, add registrars, and other essential operational steps.
**To install Namingo on Ubuntu 24.04 LTS with PHP 8.3 and MariaDB 10.11.8, use the automated installer currently provided.**
After completing the installation, please refer to the [Configuration Guide](configuration.md) to tailor the system to your specific requirements. Once configured, visit the [Initial Operation Guide](iog.md) for detailed instructions on how to set up your registry, add registrars, and perform other essential operational tasks.
***To upgrade from v1.0.0-RC4 or v1.0.0-RC5, please see our [upgrade guide](upgrade.md)***
@ -401,14 +397,6 @@ composer install
This command will install the dependencies defined in your ```composer.json``` file, ensuring that your control panel has all the necessary components to operate effectively.
### Install Optional Dependencies:
Execute the following command to install the optional dependencies:
```bash
composer require phpmailer/phpmailer
```
### Creating an Admin User:
1. Navigate to the 'bin' Directory: Change to the 'bin' subdirectory where the admin user creation script is located. (```create_admin_user.php```)
@ -437,27 +425,6 @@ To setup the correct owner of the panel cache directory, please run the followin
chown www-data:www-data /var/www/cp/cache
```
### Setting Up Redis Session Storage:
To utilize Redis for session storage, you need to install the necessary packages and configure your environment accordingly. Follow these steps to set up Redis session storage:
```bash
cd /var/www/cp
composer require predis/predis pinga/session-redis
```
After installation, log out of your application if you are currently logged in. This ensures that the session starts afresh with the new configuration.
Clear your browser cookies related to the application. This step is crucial as it removes any existing session cookies that were set using the previous session storage mechanism.
Upon your next login, Redis will be used for storing session data. The new sessions will be created and managed through Redis, providing a more scalable and efficient session management system.
**Note**: Ensure that your Redis server is properly configured and running before proceeding with these steps. If in doubt, check with:
```bash
systemctl status redis-server
```
## 8. Setup Web Lookup:
```bash
@ -548,118 +515,6 @@ mv config.php.dist config.php
Configure all options in ```config.php```.
### Install Optional Dependencies:
Execute one of the following commands to install the optional dependencies:
```bash
composer require utopia-php/messaging
```
or
```bash
composer require phpmailer/phpmailer
```
This command will install one of the packages which are essential for the message broker script to function correctly.
### Configuring the Message Broker
You can easily configure the message broker for email delivery in ```config.php```. It is compatible with SendGrid, Mailgun API, and PHPMailer for those opting to use their own SMTP server. All necessary settings are conveniently located under the mailer_ lines within the file.
For establishing your own mail server, Mox, available at [GitHub](https://github.com/mjl-/mox), provides a comprehensive solution. Install Mox following its GitHub instructions, then enter the required details in the ```config.php``` file.
To run the Message Broker, execute the following commands:
```bash
/usr/bin/php /opt/registry/automation/msg_producer.php &
/usr/bin/php /opt/registry/automation/msg_worker.php &
```
This will start the system and place it in the background, allowing it to run independently of your current terminal session.
### Setting Up an Audit Trail Database for Namingo
To create an audit trail database for Namingo, start by editing the configuration file located at `/opt/registry/automation/audit.json` with the correct database details. This includes specifying the database connection parameters such as host, username, and password. Once your configuration is set up, run the command:
```bash
/opt/registry/automation/vendor/bin/audit -v audit /opt/registry/automation/audit.json
```
This will initialize and configure the audit trail functionality. This process ensures that all necessary tables and structures are set up in the registryAudit database, enabling comprehensive auditing of Namingo's operations.
**Currently, the audit trail setup for Namingo is supported only with MySQL or MariaDB databases. If you're using PostgreSQL, you'll need to utilize an external tool for audit logging, such as [pgAudit](https://minervadb.com/index.php/pgaudit-open-source-postgresql-audit-logging/), which provides detailed audit logging capabilities tailored for PostgreSQL environments.**
### Setup Backup
To ensure the safety and availability of your data in Namingo, it's crucial to set up and verify automated backups. Begin by editing the ```backup.json``` file in the automation directory, where you'll input your database details. Ensure that the details for the database are accurately entered in two specified locations within the ```backup.json``` file.
Additionally, check that the cronjob for PHPBU is correctly scheduled on your server, as this automates the backup process. You can verify this by reviewing your server's cronjob list. These steps are vital to maintain regular, secure backups of your system, safeguarding against data loss and ensuring business continuity.
### RDE (Registry data escrow) configuration:
#### Generate the Key Pair:
Create a configuration file, say key-config, with the following content:
```yaml
%echo Generating a default key
Key-Type: RSA
Key-Length: 2048
Subkey-Type: RSA
Subkey-Length: 2048
Name-Real: Your Name
Name-Comment: Your Comment
Name-Email: your.email@example.com
Expire-Date: 0
%no-protection
%commit
%echo done
```
Replace "Your Name", "Your Comment", and "your.email@example.com" with your details.
Use the following command to generate the key:
```bash
gpg2 --batch --generate-key key-config
```
Your GPG key pair will now be generated.
#### Exporting Your Keys:
Public key:
```bash
gpg2 --armor --export your.email@example.com > publickey.asc
```
Replace `your-email@example.com` with the email address you used when generating the key.
Private key:
```bash
gpg2 --armor --export-secret-keys your.email@example.com > privatekey.asc
```
#### Secure Your Private Key:
Always keep your private key secure. Do not share it. If someone gains access to your private key, they can impersonate you in cryptographic operations.
#### Use in RDE deposit generation:
Please send the exported `publickey.asc` to your RDE provider, and also place the path to `privatekey.asc` in the escrow.php system as required.
### Running the Automation System
Once you have successfully configured all automation scripts, you are ready to initiate the automation system. Please review ```/opt/registry/automation/cron.php``` and enable all services if you are running a gTLD. Then proceed by adding the following cron job to the system crontab using ```crontab -e```:
```bash
* * * * * /usr/bin/php /opt/registry/automation/cron.php 1>> /dev/null 2>&1
```
## 13. Setup DAS:
```bash
@ -678,364 +533,4 @@ systemctl start das.service
systemctl enable das.service
```
After that you can manage DAS via systemctl as any other service.
## 14. Setup Hidden Master DNS with BIND:
Although Namingo is equipped with BIND by default for this purpose, you can opt for NSD, or Knot DNS if you are more comfortable with those systems.
### Install BIND9 and its utilities with:
```bash
apt install bind9 bind9-utils bind9-doc
```
### Generate a TSIG key:
Generate a TSIG key which will be used to authenticate DNS updates between the master and slave servers. **Note: replace ```test``` with your TLD.**
```bash
cd /etc/bind
tsig-keygen -a HMAC-SHA256 test.key
```
The output will be in the format that can be directly included in your BIND configuration files. It looks something like this:
```bash
key "test.key" {
algorithm hmac-sha256;
secret "base64-encoded-secret==";
};
```
Copy this output for use in the configuration files of both the master and slave DNS servers. (```/etc/bind/named.conf.local```)
### Configure the Named Configuration File (Please Choose One):
1. Without DNSSEC:
Edit the named.conf.local file:
```bash
nano /etc/bind/named.conf.local
```
Add the following zone definition:
```bash
zone "test." {
type master;
file "/var/lib/bind/test.zone";
allow-transfer { key "test.key"; };
also-notify { <slave-server-IP>; };
};
```
Replace ```<slave-server-IP>``` with the actual IP address of your slave server. Replace ```test``` with your TLD.
Use rndc to reload BIND:
```bash
systemctl restart bind9
```
Configure the `Zone Writer` in Registry Automation and run it manually the first time.
```bash
php /opt/registry/automation/write-zone.php
```
2. Using DNSSEC with BIND9:
Edit the named.conf.local file:
```bash
nano /etc/bind/named.conf.local
```
Add the following DNSSEC policy:
```bash
dnssec-policy "namingo-policy" {
keys {
ksk lifetime P3M algorithm ed25519;
zsk lifetime P1M algorithm ed25519;
};
max-zone-ttl 86400;
dnskey-ttl 3600;
zone-propagation-delay 3600;
parent-propagation-delay 7200;
parent-ds-ttl 86400;
};
```
Add the following zone definition:
```bash
zone "test." {
type master;
file "/var/lib/bind/test.zone";
dnssec-policy "namingo-policy";
key-directory "/var/lib/bind";
inline-signing yes;
allow-transfer { key "test.key"; };
also-notify { <slave-server-IP>; };
};
```
Replace ```<slave-server-IP>``` with the actual IP address of your slave server. Replace ```test``` with your TLD.
Initially, you will need to generate the DNSSEC ZSK and KSK manually:
```bash
dnssec-keygen -a Ed25519 -n ZONE test.
dnssec-keygen -a Ed25519 -n ZONE -f KSK test.
```
After generating the keys, place them in ```/var/lib/bind```. Run ```dnssec-dsfromkey Ktest.EXAMPLE.key``` on the KSK key you just generated, and the DS record must be submitted to IANA once setup is complete.
Use rndc to tell BIND to load and use the new keys:
```bash
systemctl restart bind9
rndc loadkeys test.
```
Configure the `Zone Writer` in Registry Automation and run it manually the first time.
```bash
php /opt/registry/automation/write-zone.php
```
3. Using DNSSEC with OpenDNSSEC:
Edit the named.conf.local file:
```bash
nano /etc/bind/named.conf.local
```
Add the following zone definition:
```bash
zone "test." {
type master;
file "/var/lib/bind/test.zone.signed";
allow-transfer { key "test.key"; };
also-notify { <slave-server-IP>; };
};
```
Replace ```<slave-server-IP>``` with the actual IP address of your slave server. Replace ```test``` with your TLD.
Install OpenDNSSEC:
```bash
apt install opendnssec opendnssec-enforcer-sqlite3 opendnssec-signer softhsm2
```
Update files in `/etc/opendnssec` to match your registry policy. As minimum, please enable at least Signer Threads in `/etc/opendnssec/conf.xml`, but we recommend to fully review [all the files](https://wiki.opendnssec.org/configuration/confxml/). Then run the following commands:
```bash
softhsm2-util --init-token --slot 0 --label OpenDNSSEC --pin 1234 --so-pin 1234
ods-enforcer-db-setup
rm /etc/opendnssec/prevent-startup
ods-control start
ods-enforcer policy import
ods-enforcer zone add -z test -p default -i /var/lib/bind/test.zone
```
Use rndc to reload BIND:
```bash
systemctl restart bind9
```
Configure the `Zone Writer` in Registry Automation and run it manually the first time.
```bash
php /opt/registry/automation/write-zone.php
```
### Check BIND9 Configuration:
```bash
named-checkconf
named-checkzone test /var/lib/bind/test.zone
```
### Restart BIND9 Service:
```bash
systemctl restart bind9
```
### Verify Zone Loading:
Check the BIND9 logs to ensure that the .test zone is loaded without errors:
```bash
grep named /var/log/syslog
```
### 14.1 Regular DNS Server Setup:
Before editing the configuration files, you need to copy the TSIG key from your hidden master server. The TSIG key configuration should look like this:
```bash
key "test.key" {
algorithm hmac-sha256;
secret "base64-encoded-secret==";
};
```
#### Installation of BIND9:
```bash
apt update
apt install bind9 bind9-utils bind9-doc
```
#### Add the TSIG key to the BIND Configuration:
Create a directory to store zone files:
```bash
mkdir /var/cache/bind/zones
```
Edit the `named.conf.local` file:
```bash
nano /etc/bind/named.conf.local
```
First, define the TSIG key at the top of the file:
```bash
key "test.key" {
algorithm hmac-sha256;
secret "base64-encoded-secret=="; // Replace with your actual base64-encoded key
};
```
Then, add the slave zone configuration:
```bash
zone "test." {
type slave;
file "/var/cache/bind/zones/test.zone";
masters { 192.0.2.1 key "test.key"; }; // IP of the hidden master and TSIG key reference
allow-query { any; }; // Allow queries from all IPs
allow-transfer { none; }; // Disable zone transfers (AXFR) to others
};
```
Make sure to replace `192.0.2.1` with the IP address of your hidden master server and `base64-encoded-secret==` with the actual secret from your TSIG key.
#### Adjusting Permissions and Ownership:
Ensure BIND has permission to write to the zone file and that the files are owned by the BIND user:
```bash
chown bind:bind /var/cache/bind/zones
chmod 755 /var/cache/bind/zones
```
#### Restart BIND9 Service:
After making these changes, restart the BIND9 service to apply them:
```bash
systemctl restart bind9
```
#### Verify Configuration and Zone Transfer:
```bash
named-checkconf
grep 'transfer of "test."' /var/log/syslog
```
## 15. Setup Monitoring:
For effective monitoring of your registry system, we highly recommend utilizing Prometheus.
```bash
wget https://github.com/prometheus/prometheus/releases/download/v2.48.1/prometheus-2.48.1.linux-amd64.tar.gz
tar xvfz prometheus-2.48.1.linux-amd64.tar.gz
cp prometheus-2.48.1.linux-amd64/prometheus /usr/local/bin/
cp prometheus-2.48.1.linux-amd64/promtool /usr/local/bin/
useradd --no-create-home --shell /bin/false prometheus
mkdir /etc/prometheus
mkdir /var/lib/prometheus
cp -r prometheus-2.48.1.linux-amd64/consoles /etc/prometheus
cp -r prometheus-2.48.1.linux-amd64/console_libraries /etc/prometheus
chown -R prometheus:prometheus /etc/prometheus
chown -R prometheus:prometheus /var/lib/prometheus
```
Place the following in the ```/etc/prometheus/prometheus.yml``` and customize as needed:
```
# Global settings and defaults.
global:
scrape_interval: 15s # By default, scrape targets every 15 seconds.
evaluation_interval: 15s # Evaluate rules every 15 seconds.
# Alertmanager configuration (commented out by default).
# alerting:
# alertmanagers:
# - static_configs:
# - targets:
# - localhost:9093
# Load and evaluate rules in this file.
# rule_files:
# - "first_rules.yml"
# - "second_rules.yml"
# Scrape configuration for running Prometheus on the same machine.
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: 'prometheus'
# metrics_path defaults to '/metrics'
# scheme defaults to 'http'.
static_configs:
- targets: ['localhost:9090']
# Example job for scraping an HTTP service.
- job_name: 'http_service'
static_configs:
- targets: ['<your_http_service>:80']
# Example job for scraping an HTTPS service.
- job_name: 'https_service'
static_configs:
- targets: ['<your_https_service>:443']
# Example job for scraping a DNS server.
- job_name: 'dns_monitoring'
static_configs:
- targets: ['<your_dns_server>:53']
# Add additional jobs as needed for your services.
```
Run the monitoring tool using:
```bash
prometheus --config.file=/etc/prometheus/prometheus.yml
```
The tool will be available at ```http://<your_server_ip>:9090```
## 16. Recommended Help Desk Solution:
If you're in need of an effective help desk solution to complement your experience with Namingo, we recommend considering [FreeScout](https://freescout.net/), an AGPL-3.0 licensed, free and open-source software. FreeScout is known for its user-friendly interface and robust features, making it an excellent choice for managing customer queries and support tickets.
### Please Note:
- FreeScout is an independent software and is not a part of Namingo. It is licensed under the AGPL-3.0, which is different from Namingo's MIT license.
- The recommendation to use FreeScout is entirely optional and for the convenience of Namingo users. Namingo functions independently of FreeScout and does not require FreeScout for its operation.
- Ensure to comply with the AGPL-3.0 license terms if you choose to use FreeScout alongside Namingo.
After that you can manage DAS via systemctl as any other service.

20
docs/iog.md
View file

@ -2,11 +2,14 @@
Welcome to the Initial Operation Guide for Namingo. This document is designed to assist you in the initial setup and operation of your Namingo system. Follow these steps to ensure a smooth start and efficient management of your domain registry.
## Deleting Test Data
1. **Deleting Registrars and Test TLDs**: To delete test registrars and TLDs, edit the `/opt/registry/tests/clean-test-details.php` script with your database details and then execute it. It is advisable to delete test data before adding new data to the system.
## Logging into the Control Panel
1. **Access the Panel**: Begin by logging in to the control panel as the registry administrator. This is the user account you created during the installation process.
2. **Familiarize Yourself**: Once logged in, take some time to explore the interface and familiarize yourself with the various features and settings available.
3. **Test the System**: Try creating a contact in the system, and then using this contact to register a domain under one of your test TLDs. This practical exercise allows you to experience the end-to-end process of domain registration as your registrars would. After registering the domain, make use of the WHOIS and RDAP services to verify the domain's addition to the system. This process not only familiarizes you with Namingo's functionality but also ensures that all components of your registry are functioning as expected. It's an excellent way to validate your setup and prepare for managing live domain registrations.
## Configuring Your Registry
@ -29,16 +32,19 @@ Welcome to the Initial Operation Guide for Namingo. This document is designed to
- **Pricing**: Set prices for registration and renewal.
- **Premium Names**: Define any premium domain names.
3. **Manage Reserved Names**: In this section, you can also manage names that are reserved and not available for general registration.
4. **Deleting Test TLDs**: Currently, test TLDs can only be removed directly from the database. For this, please contact the Namingo support team for assistance.
4. **Update Configuration Files**: Edit `/opt/registry/epp/config.php` and `/var/www/cp/.env` to set the `test_tlds` variables to your TLD(s).
## Managing Registrars
1. **Create a Registrar**: Navigate to the `registrars` section and choose to create a new registrar.
2. **Add Your First Registrar**: Fill in the required details to add your first registrar to the system.
3. **Deleting Registrars**: Similar to test TLDs, registrars can currently only be deleted via the database. Contact the Namingo support team for any such requests.
1. **Create a Registrar**: Navigate to the **Registrars** section, select **Create Registrar** from the menu, and fill in the required details to add your first registrar to the system.
## Testing Your Registry Setup
1. **Create a Contact**: Begin by creating a contact in the system. This contact will be used in the domain registration process.
2. **Register a Domain**: Use the contact you created to register a domain under one of your TLDs. This step will help you experience the end-to-end process of domain registration just as your registrars would.
3. **Verify with WHOIS and RDAP**: After registering the domain, utilize the WHOIS and RDAP services to verify that the domain has been successfully added to the system.
4. **Validate the Setup**: Completing this process not only familiarizes you with the platform’s functionality but also serves as a validation to ensure all components of your registry are functioning as expected. This step is crucial in preparing for managing live domain registrations.
---
As you proceed with these initial steps, keep in mind that the Namingo support team is available to assist you with any queries or issues. This guide is your first step towards managing a robust and efficient domain registry with Namingo.
Upon completing the steps outlined above, you are now fully equipped to manage your domain registry using Namingo. With the registry and TLD configurations set, and your first registrar added, your system is operational and ready for domain management. This marks a significant milestone in your journey with Namingo, paving the way for efficient and streamlined registry operations. Remember, the Namingo platform is designed to be intuitive and user-friendly, ensuring a smooth management experience as you grow and evolve your domain registry services.