> For the complete documentation index, see [llms.txt](https://docs.storware.eu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.storware.eu/deployment/first-steps-after-installation/node-configuration.md). # Node Configuration ## Overview After installing Storware Backup & Recovery, configure each Node and register it with the Server. This procedure covers HTTPS connectivity, operating system configuration, LVM filtering for disk attachment, Node registration, and service verification. Run commands as `root` on the indicated host. Replace example hostnames, addresses, and passwords with the values used in your environment. ## Configuration steps ### 1. Configure HTTPS Connectivity The examples use `storware.example.com` and HTTPS port `8181`. If port `443` is configured, use it consistently instead. #### 1.1. Select the Server Hostname Use a fully qualified domain name (FQDN) matching the Server certificate. | Deployment | Hostname to use | | --------------------------------------------------------------- | ------------------------------------------- | | Server and Node on the same host, using the default certificate | `localhost.localdomain` | | Node connecting to a separate Server | Server FQDN, such as `storware.example.com` | | High-availability Server | Shared cluster FQDN | For local connections using the default certificate, use `localhost.localdomain`, not `localhost`. Remote connections require a certificate matching the Server FQDN. **On each Node**, verify name resolution: ``` getent hosts storware.example.com ``` If DNS is unavailable, add the appropriate entry to `/etc/hosts`: ``` 10.1.1.5 storware.example.com ``` #### 1.2. Prepare the Server Certificate **Run on the Server.** If the Server already presents a valid certificate for the selected hostname, continue with **Trust the Server Certificate on the Node**. Otherwise, prepare either a self-signed certificate or a certificate signed by your certificate authority (CA). Create a protected working directory: ``` install -d -m 700 /root/storware-tls cd /root/storware-tls umask 077 ``` **Option A: Self-Signed Certificate** Generate an encrypted private key and a certificate containing the Server hostname in the Subject Alternative Name (SAN): ``` openssl req -x509 -newkey rsa:4096 -sha256 \ -keyout storware.key \ -out storware.crt \ -days 365 \ -subj "/CN=storware.example.com" \ -addext "subjectAltName=DNS:storware.example.com" ``` Enter a private-key passphrase when prompted. **Option B: CA-Signed Certificate** Generate an encrypted private key and a certificate signing request (CSR): ``` openssl req -new -newkey rsa:4096 -sha256 \ -keyout storware.key \ -out storware.csr \ -subj "/CN=storware.example.com" \ -addext "subjectAltName=DNS:storware.example.com" ``` Submit `storware.csr` to your CA. Save the issued certificate as `storware.crt` and any intermediate certificates as `ca-chain.crt`. #### 1.3. Create the Server Keystore **Run on the Server, from `/root/storware-tls`.** For a self-signed certificate: ``` openssl pkcs12 -export \ -in storware.crt \ -inkey storware.key \ -out storware.p12 \ -name storware ``` For a CA-signed certificate with intermediate certificates: ``` openssl pkcs12 -export \ -in storware.crt \ -inkey storware.key \ -certfile ca-chain.crt \ -out storware.p12 \ -name storware ``` Provide the private-key passphrase and choose an export password. The PKCS12 bundle contains the private key and certificate chain. Import the bundle into a new Java keystore: ``` keytool -importkeystore \ -srckeystore storware.p12 \ -srcstoretype PKCS12 \ -destkeystore /opt/vprotect/server/https-keystore.jks \ -deststoretype JKS \ -alias storware ``` Use the **same password for the PKCS12 export and destination keystore**, so the imported private key and keystore have matching passwords. The destination filename must not contain an unrelated existing keystore. [docs.oracle.com](https://docs.oracle.com/en/java/javase/21/docs/specs/man/keytool.html?utm_source=chatgpt.com) Set ownership and permissions: ``` chown vprotect:vprotect /opt/vprotect/server/https-keystore.jks chmod 600 /opt/vprotect/server/https-keystore.jks ``` Back up `/opt/vprotect/server/quarkus.properties`, then update its existing keystore settings: ``` javax.net.ssl.keyStore=/opt/vprotect/server/https-keystore.jks javax.net.ssl.keyStorePassword= ``` Use the **destination keystore password**, not the original private-key passphrase. Restart the Server: ``` systemctl restart vprotect-server ``` #### 1.4. Trust the Server Certificate on the Node **Run on each Node.** Inspect the certificate presented by the Server: ``` openssl s_client \ -connect storware.example.com:8181 \ -servername storware.example.com \ -showcerts ' ``` This password belongs to the **Node truststore**, independently of the Server keystore password. For a local Node using the default certificate: ``` /opt/vprotect/node/scripts/node_add_ssl_cert.sh \ localhost.localdomain 8181 ``` Repeat certificate verification and import when a certificate change requires updating the Node’s truststore. ### 2. Configure the Operating System **Run on each Node.** Execute: ``` vprotect-node-configure ``` The documented configuration script adjusts QEMU ownership settings, adds the `vprotect` account to the disk group, configures privileged command access through sudoers, and disables SELinux. Allow the script to complete successfully before continuing. These changes affect the host’s operating system configuration. ### 3. Configure LVM for Disk Attachment Complete this section if the Node operates as a proxy VM using a **disk attachment backup strategy**. Otherwise, proceed to **Register the Node**. Attached backup disks can contain LVM metadata identical to the Node’s own disks, particularly when VMs originate from the same template. Restrict host LVM scanning to the Node’s own required devices to avoid discovering or activating volume groups from attached backup disks. #### 3.1. Identify the Node’s Disks **Run on the Node before attaching backup disks.** Inspect the device layout: ``` lsblk -o NAME,PATH,TYPE,FSTYPE,MOUNTPOINTS pvs -o pv_name,vg_name vgs lvs -o lv_name,vg_name,devices ``` Identify every physical volume required by the Node, including devices containing root, swap, and any other local LVM filesystems. Back up the LVM configuration: ``` cp -a /etc/lvm/lvm.conf /etc/lvm/lvm.conf.before-storware ``` #### 3.2. Configure Device Filters Edit the existing `devices` section in `/etc/lvm/lvm.conf`. The following example assumes that **all required local LVM devices are on `/dev/sda`**: ``` devices { filter = [ "a|^/dev/sda$|", "a|^/dev/sda[0-9]+$|", "r|.*|" ] global_filter = [ "a|^/dev/sda$|", "a|^/dev/sda[0-9]+$|", "r|.*|" ] } ``` The acceptance rules permit the specified disk and its partitions. The final rule rejects other devices. Adapt both filters to include every required local device. For production configurations, prefer stable `/dev/disk/by-id/` paths where appropriate, because kernel device names can change. {% hint style="info" %} **Important:** Do not copy the `/dev/sda` example without checking your layout. Excluding a required system disk can prevent the Node from booting. {% endhint %} #### 3.3. Account for the LVM Devices File On RHEL 9, the devices file is enabled by default and replaces ordinary LVM filtering. To use the filter-based configuration above, also set the following in the same `devices` section: ``` use_devicesfile = 0 ``` On other systems, apply this setting only if their LVM version supports the devices-file feature. #### 3.4. Validate the Configuration Verify that the Node’s required volume groups and logical volumes remain visible: ``` vgscan -vvv pvs vgs lvs ``` If required volumes are missing, correct the filters or restore the saved configuration **before rebooting**. On RHEL systems, rebuild the initramfs after validating the filters: ``` dracut --force ``` This makes the updated filtering available during boot. ### 4. Register the Node **Run on each Node.** Register the Node with an administrative Server account: ``` vc node inst register \ --name='' \ --login='' \ --password='' \ --apiurl='https://storware.example.com:8181/api' ``` | Parameter | Description | | ------------ | ----------------------------------------------------------- | | `--name` | Name identifying the Node in Storware Backup & Recovery. | | `--login` | Administrative account used for registration. | | `--password` | Password for that account. | | `--apiurl` | Server API URL, including the HTTPS port and `/api` suffix. | Use the same hostname and port as in the certificate configuration. For a local Node using the default certificate, set: ``` https://localhost.localdomain:8181/api ``` Confirm that registration succeeds before proceeding. ### 5. Reboot and Verify the Node Reboot the Node host to apply the operating system changes: ``` reboot ``` After reconnecting, check the service: ``` systemctl status vprotect-node ``` The expected state is `active (running)`. Also verify in the web interface that the registered Node is connected. #### Troubleshooting If the Node fails to start or connect, check: * Server hostname resolution and network reachability. * Whether the configured port matches the actual HTTPS endpoint. * Certificate hostname, expiry, and trust. * Registration credentials and API URL. * Availability of the Node’s required local volumes after LVM configuration. Inspect service messages: ``` journalctl -u vprotect-node -b --no-pager -n 100 ``` Application logs are stored under: ``` /opt/vprotect/logs ```