Hardware Incident Response: Memory Slot Failure on banshee

2025-06-12T09:29:37Z

Alois: /* Confirm it's a hardware issue */

Hardware Incident Response: Memory Slot Failure on banshee

2025-06-12T09:27:08Z

Alois:

File:Banshee.idrac.ws.maxmaton.nl restgui index.html 8ce2fb21ce62c14bc4975f040b973a5f(1).png

2025-06-12T09:26:04Z

Alois:

Banshee Hardware health iDrac

Hardware Incident Response: Memory Slot Failure on banshee

2025-06-12T09:00:12Z

Alois:

Hardware Incident Response: Memory Slot Failure on banshee

2025-06-12T08:57:20Z

Alois: Created page with "This document outlines how we handled a memory stick failure on the server banshee. It details the actual steps we took, the tools and commands we used, and the reasoning behind our decisions. ⚠️ Important: This is not a universal or comprehensive guide. Hardware failures — including memory issues — can vary widely in symptoms and impact. There may be multiple valid ways to respond depending on the urgency or available resources. This write-up should be seen as..."

This document outlines how we handled a memory stick failure on the server banshee. It details the actual steps we took, the tools and commands we used, and the reasoning behind our decisions.

⚠️ Important: This is not a universal or comprehensive guide. Hardware failures — including memory issues — can vary widely in symptoms and impact. There may be multiple valid ways to respond depending on the urgency or available resources.

This write-up should be seen as one practical example that may help guide similar interventions in the future or serve as a starting point when assessing next steps in a hardware-related incident.

Internal

2025-06-12T08:54:44Z

Alois: /* SRE */

== Strategy ==
* [[Flow metrics|Flow metrics]]
* [[12%-time|12%-time]]

== Finance ==

=== Exact ===

* [[booking bonus|Booking bonus]]
* [[booking wages|Booking wages]]
* [[booking quarterly hosting invoice|Booking quarterly hosting invoice]]
* [[new receipt|Enter a new receipt]]
* [[reconciliation|Reconciliation of transaction]]
* [[invoicing|Send an invoice]]
* [[payment reminders|Send payment reminder]]
* [[invoice approval|Process for approving invoices (/filed receipts)]]

=== Bunq ===

* [[top up account|Top up expense account]]

== Work Process ==

* [[Definition of done|Definition of Done]]
* [[Incident Handling|Incident Handling]]
* [[SRE Maintenance|SRE Maintenance]]
* [[Release checklist|Release checklist]]

== Internal Process ==
* [[timetracking|Timetracking process]]
* [[Starting work for a new client]]
* [[12 percent|12% time]]
* [[Annual leave|Annual leave]]
* [[Bonus allocation|Bonus allocation]]
* [[Calamity leave|Calamity leave]]
* [[Overtime|Overtime]]
* [[Retrospectives|Retrospectives]]
* [[Sick leave|Sick leave]]
* [[Training and self-study|Training and Self-Study]]
* [[Daily|Daily]]

== Projects ==

* Era Inventory [[project_era_inventory_api|API Description]]

== SRE ==

''To be further populated with guide from drive''
* [[create gitlab runner host|Create a GitLab runner host]]
* [[vm setup|Create a (Debian) VM]]
* [[border update|Process for updating a border]]
* [[border reboot|Reboot border without downtime]]
* [[WS Proxmox node reboot|Reboot WS Proxmox node without downtime]]
* [[Resize VM Disk]]
* [[SRE tools]]
* [[Enroll Mac in Kerberos]]
* [[New Mac Setup]]
* [[Creating a VM on Hetzner]]
* [[Rebooting VM]]
* [[Rebooting Offsite]]
* [[ssh-fingerprints|Verifying SSH fingerprints]]
* [[Removing VM]]
* [[Install a new Disk in Server]]
* [[Setting Up Wildcard Subdomains with SSL on a Debian Application]]
* [[Hardware Incident Response: Memory Slot Failure on banshee]]
=== SLA ===
* [[Response for Backup Service being down for an extended period of time]]

== Other ==

* [[stack|Greenfield stack]]
* [[standard tools|Standard Tools]]
* [[list of unfurl debuggers|List of unfurl debuggers]]
* [[Recommended suppliers]]

Removing VM

2025-06-10T13:56:44Z

Alois:

This guide was written with the general idea of undoing the steps from our [https://docs.google.com/document/d/1UWESupnHD5jVHTAhdngAH5_HGViwDL_7G5xTX4b9CYs VM Setup guide] going in reverse order.

=== Step 1 : Disable the host on Zabbix ===
This avoids having to create a maintenance period for the next step.
This can be done 2 ways:
*1st way : In Zabbix > Configuration > Hosts find the VM you want to disable, in the “status” column you should see “Enabled”, click “Enabled” to disable the VM you’ll get a confirmation prompt.
[[File:Screenshot 2024-09-02 at 11.04.36.png|200px|thumb|center|disabling host confirmation prompt]]

*2nd way : In Zabbix > Configuration > Hosts, find the VM you want to disable, click its name, a configuration panel appears, uncheck the “Enabled” checkbox
[[File:Screenshot 2024-09-02 at 11.07.07.png|200px|thumb|center|alt=Zabbix configuration panel|configuration panel]]

=== Step 2 : Remove VM from HA group ===
In Proxmox
*1. From your VM panel go to More > Manage HA in the top right corner
[[File:Proxmox-more-ha.png|200px|thumb|center|alt=location of the "Manage HA" option|location of the "Manage HA" option]]
*2. Set Request State to “stopped”
[[File:Screenshot 2024-09-02 at 11.33.16.png|200px|thumb|center|alt=HA config panel|HA config panel]]

=== Step 3 : Undo IPA enrollment ===
'''This step can only be performed by the First Responder '''

*1. Select the desired hostname and click delete
[[File:IPA-Hosts-Panel.png|200px|thumb|center|alt=IPA hosts panel|IPA hosts panel]]

*2. This will open a modal, make sure to check the option to remove all A, AAAA, SSHFP and PTR records
[[File:IPA-host-removal.png|200px|thumb|center|alt=Host removal confirmation prompt|Host removal confirmation prompt]]

=== Step 4 : Remove all references ===
Remove any reference of your VM from our [https://git.dsinternal.net/delft-solutions/infrastructure/dns DNS repo]

=== Step 5 : Remove the vm on proxmox ===
quick note: make sure to note down the vm's id as it will be needed for step 6

*1. From your vm panel go to More > Remove, in the top right corner
[[File:Proxmox-vm-removal-location.png|200px|thumb|center|alt=Proxmox vm removal option location|Proxmox vm removal option location]]

*2. This will open a modal, make sure to check all boxes and confirm the id of the VM you’re removing
[[File:VM-removal-confirmation-prompt.png|200px|thumb|center|alt=VM removal confirmation panel|VM removal confirmation panel]]

=== Step 6 : Purge any backup data ===

*1. Backups are stored in zombie.maxmaton.nl at the time this guide is written, because this is a third party service we can not purge the data ourselves. Ask Max to purge backup data providing him with the id of the VM you want to purge backup data for.

2024-10-31T14:04:30Z

Alois:

This guide provides a step-by-step approach to setting up wildcard subdomains with SSL on a Debian-based application. Wildcard subdomains allow applications to dynamically support multiple subdomains (abc.example.com, xyz.example.com) under a single SSL certificate.

In this guide, the focus is on configuring a Debian package to handle wildcard subdomains primarily through updates to the debian/postinst file. The guide uses the ''kaboom-api'' app as an example, with <code>staging-elearning.nl</code> as the domain name on which we’re setting up wildcard subdomains.

If you do not need or prefer not to modify the application code itself, you can still follow the key steps and commands described in this guide directly from the terminal. This will allow you to set up SSL for wildcard subdomains without diving into the application’s Debian packaging configuration.

By the end of this guide, you will have a fully automated process for configuring and renewing SSL certificates for wildcard subdomains, leveraging tools like Certbot and DNS authentication.

== Prerequisites ==

=== 1. DNS Configuration for Wildcard Subdomains ===

Access your DNS repository and add the necessary A and AAAA records for the wildcard subdomain you plan to use. This typically involves adding entries like <code>*.example.com</code> pointing to your server’s IP address.

The following is an example of what has been done for the domain name <code>staging-elearning.nl</code>

<code>staging-elearning.nl.zone</code>
<pre lang="bash">
$ORIGIN staging-elearning.nl.
$TTL 3600
@ IN 3600 SOA delftsolutions.ns1.signaldomain.nl. info.signaldomain.nl. (
<serial> ; don't modify, auto incremented
86400 ; secondary refresh
7200 ; secondary retry
3600000 ; secondary expiry
600 ; negative response ttl
)

@ 3600 IN NS ns2.signaldomain.net.
@ 3600 IN NS delftsolutions.ns1.signaldomain.nl.

* IN 3600 A 193.5.147.172
* IN 3600 AAAA 2a0c:8187:0:201::196
</pre>

=== 2. Required Packages ===

* python3-certbot-dns-rfc2136
* openssl
* nginx
* dnsutils
* certbot

== Configuring SSL and Wildcard Subdomains ==

=== 1. Handling Environment Variables ===

We’ll first add three environment variables to capture essential information: DNS_AUTHENTICATION, CERTBOT_EMAIL, and FQDN. These variables will be defined using Debconf, which allows us to prompt for values during installation and configuration.

'''DNS_AUTHENTICATION''': This string is required for Certbot’s DNS-based challenge verification. The format includes a keyname, algorithm, and secret for authentication, followed by the authoritative DNS hostname.
This string is currently obtained using the signal domain api package running the command :
<code>signaldomain-api key certbot create <domain_name></code>

The expected format is: <code>dns://<key_name>:<key_algorithm>~<key_secret_base64>@<authoritive_nameserver_domainname></code>

example: <code>dns://staging-elearning_nl__certbot._keys.delftsolutions.signaldomain._internal.usersignal.nl.:hmac-sha256~<key_secret>@ns1.signaldomain.nl/staging-elearning_nl__certbot._keys.delftsolutions.signaldomain._internal.usersignal.nl.</code>

'''CERTBOT_EMAIL''': This email address is used when registering an account with Let’s Encrypt. Important notifications about certificate issues will be sent to this address.

'''FQDN''': This is the fully qualified domain name of the primary domain for which wildcard SSL certificates will be issued. <code>staging-elearning.nl</code> for this guide example.

Here’s how to set these variables in <code>debian/templates</code>, define prompts in <code>debian/config</code>, and retrieve them in <code>debian/postinst</code>.

in <code>debian/templates</code>, add the following entries to create prompt templates for each variable:
<pre lang="bash">
…
Template: <PKG_NAME>/DNS_AUTHENTICATION
Type: string
Default:
Description: DNS authentication string in the following format: dns://<key_name>:<key_algorithm>~<key_secret_base64>@<authoritative_nameserver_domainname>

Template: <PKG_NAME>/CERTBOT_EMAIL
Type: string
Default:
Description: Enter the email that certificate issues should be reported to. Entering this will result in accepting the Let's Encrypt terms and conditions.

Template: <PKG_NAME>/FQDN
Type: string
Default:
Description: Enter the fully qualified domain name for ...
…
</pre>
<code><PKG_NAME></code> is the name of your Debian package, <code>kaboom-api</code> in our case.

Add the following lines to your <code>debian/config</code> file to prompt for these variables during configuration:
in <code>debian/templates</code>, add the following entries to create prompt templates for each variable:

<pre lang="bash">
…
db_input medium <PKG_NAME>/CERTBOT_EMAIL || true
db_input medium <PKG_NAME>/DNS_AUTHENTICATION || true
db_input medium <PKG_NAME>/FQDN || true
…
</pre>

In <code>debian/postinst</code>, retrieve the stored values with the following lines:

<pre lang="bash">
…
db_get <PKG_NAME>/DNS_AUTHENTICATION
DNS_AUTHENTICATION="$RET"

db_get <PKG_NAME>/CERTBOT_EMAIL
CERTBOT_EMAIL="$RET"

db_get <PKG_NAME>/FQDN
FQDN="$RET"
…
</pre>

These values shall be set or updated once the whole config is over, by running the following command:
<code>sudo dpkg-reconfigure <PKG_NAME></code>

=== 2. Automating SSL and Wildcard Domain Setup in postinst ===
Here we will break down concern by concern how to configure the <code>debian/postinst</code> file.

==== a. Creating the dns-auth.conf File ====

The <code>dns-auth.conf</code> file will be generated from the DNS_AUTHENTICATION variable, which contains the details for Certbot’s DNS challenge configuration. Add the following to the <code>debian/postinst</code> file to create this file:
<pre lang="bash">
dns_hostname_path="$(cut -d'@' -f2- <<<"$DNS_AUTHENTICATION")"
dns_schema_auth="$(cut -d'@' -f1 <<<"$DNS_AUTHENTICATION")"

dns_hostname="$(cut -d'/' -f1 <<<"$dns_hostname_path")"
dns_auth="$(cut -d'/' -f3- <<<"$dns_schema_auth")"
dns_auth_keyname="$(cut -d':' -f1 <<<"$dns_auth")"
dns_auth_algorithm="$(cut -d':' -f2- <<<"$dns_auth" | cut -d'~' -f1 | tr '[:lower:]' '[:upper:]')"
dns_auth_secret="$(cut -d':' -f2- <<<"$dns_auth" | cut -d'~' -f2-)"

dns_host_aaaa="$(dig +short AAAA "$dns_hostname" | head -n1)"

[ -d etc/<DNS_CONF_DIR> ] || mkdir -p etc/<DNS_CONF_DIR>

umask 266
cat > etc/<DNS_CONF_DIR>/dns-auth.conf <<CONF
# Managed by apt, please use dpkg-reconfigure <PKG_NAME> to modify
dns_rfc2136_server = $dns_host_aaaa
dns_rfc2136_port = 53
dns_rfc2136_name = $dns_auth_keyname
dns_rfc2136_secret = $dns_auth_secret
dns_rfc2136_algorithm = $dns_auth_algorithm
CONF
umask 022
</pre>

This configuration file will be used by Certbot to authenticate and verify domain ownership via DNS challenges.
In the case of our guide with the kaboom-api example, <code><DNS_CONF_DIR></code> is <code>kaboom</code>, it's up to you to select the right naming for your case.

Once the script has been executed The <code>dns-auth.conf</code> file should look something like this:

<pre lang="bash">
dns_rfc2136_server = 2a0c:8187::120
dns_rfc2136_port = 53
dns_rfc2136_name = staging-elearning_nl__certbot._keys.delftsolutions.signaldomain._internal.usersignal.nl.
dns_rfc2136_secret = <secret-key>
dns_rfc2136_algorithm = HMAC-SHA256
</pre>

Make sure that proper letter case is observed as this would cause the script to fail with unclear error messages.

==== b. Setting Up Certbot and Requesting Certificates ====

To handle SSL certificates, Certbot needs to register an account (if not already registered) and request a certificate for the primary domain and wildcard subdomain. Add the following to postinst to check and register Certbot, then request the certificate:

<pre lang="bash">
certbot_account_count="$(find /etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/ -maxdepth 1 -mindepth 1 | wc -l)"
if [ "z$certbot_account_count" = "z0" ]; then
certbot register --non-interactive --email "$CERTBOT_EMAIL" --no-eff-email --agree-tos
fi

[ ! -f "/etc/letsencrypt/live/<CERT_NAME>/fullchain.pem" ] || certbot certonly --non-interactive --cert-name <CERT_NAME> --dns-rfc2136 --dns-rfc2136-credentials etc/<DNS_CONF_DIR>/dns-auth.conf --domain "$FQDN" --domain "*.$FQDN" --deploy-hook /usr/share/<PKG_NAME>/bin/cert-deploy
</pre>

This block registers Certbot, checks for an existing certificate, and if none exists, requests a new certificate using DNS authentication with the specified dns-auth.conf file. The --deploy-hook option calls the cert-deploy file after each certificate issuance or renewal. We will create the cert-deploy in '''step f'''.

In the case of our guide with the kaboom-api example, <code><CERT_NAME></code> is <code>kaboom-elearning</code>, again it's up to you to select the right naming for your case.

==== c. Generating Diffie-Hellman Parameters for SSL ====

Diffie-Hellman parameters enhance SSL security. To ensure this file exists, add the following to <code>debian/postinst</code>:

<pre lang="bash">
[ -f "etc/<DNS_CONF_DIR>/ssl-dhparams.pem" ] || openssl dhparam -out etc/<DNS_CONF_DIR>/ssl-dhparams.pem 2048
</pre>

This code checks for an existing <code>ssl-dhparams.pem</code> file, generating one if it doesn’t exist, using 2048-bit encryption for security.

==== d. Configuring Nginx for Wildcard SSL ====

Finally, configure Nginx to handle requests for the wildcard domain and apply SSL settings. Here’s the code to create a new Nginx server block for the wildcard domain:

<pre lang="bash">
cat >/etc/nginx/sites-available/<CERT_NAME> <<CONF
server {
root /usr/share/<PKG_NAME>/public;
server_name *.$FQDN;

location / {
proxy_pass http://<APP_UPSTREAM>/;
proxy_set_header Host \$host;
proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto \$scheme;
proxy_buffers 8 32k;
proxy_buffer_size 64k;
client_max_body_size 0;
proxy_redirect off;
proxy_buffering off;
}

listen [::]:443 ssl http2;
listen 443 ssl http2;

ssl_certificate /etc/letsencrypt/live/<CERT_NAME>/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/<CERT_NAME>/privkey.pem;
ssl_dhparam etc/<DNS_CONF_DIR>/ssl-dhparams.pem;

ssl_session_cache shared:le_nginx_SSL:10m;
ssl_session_timeout 1440m;
ssl_session_tickets off;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384";
}
CONF

[ -L /etc/nginx/sites-enabled/<CERT_NAME> ] || ln -s /etc/nginx/sites-available/<CERT_NAME> /etc/nginx/sites-enabled

nginx -q -t && service nginx reload
</pre>

In the case of our guide with the kaboom-api example, <code><APP_UPSTREAM></code> is <code>kaboom-api</code>, it refers to the backend application server(s) receiving proxied requests.

==== e. Wrapping everything in an if statement ====

You do not want to run that part of the postinst script if you do not have the DNS_AUTHENTICATION, CERTBOT_EMAIL, and FQDN variables set.

This is why we’ll wrap everything we just covered inside an if statement

<pre lang="bash">
if [ -n "$DNS_AUTHENTICATION" ] && [ -n "$CERTBOT_EMAIL" ] && [ -n "$FQDN" ] ; then
#Everything we just wrote
else
echo "one or more of DNS_AUTHENTICATION, CERTBOT_EMAIL, FQDN are missing, skipping wildcard subdomains SSL certificate setup."
fi
</pre>

Here is what the finished code looks like in the kaboom-api example

<pre lang="bash">
if [ -n "$DNS_AUTHENTICATION" ] && [ -n "$CERTBOT_EMAIL" ] && [ -n "$FQDN" ] ; then

dns_hostname_path="$(cut -d'@' -f2- <<<"$DNS_AUTHENTICATION")"
dns_schema_auth="$(cut -d'@' -f1 <<<"$DNS_AUTHENTICATION")"

dns_hostname="$(cut -d'/' -f1 <<<"$dns_hostname_path")"

dns_auth="$(cut -d'/' -f3- <<<"$dns_schema_auth")"
dns_auth_keyname="$(cut -d':' -f1 <<<"$dns_auth")"
dns_auth_algorithm="$(cut -d':' -f2- <<<"$dns_auth" | cut -d'~' -f1 | tr '[:lower:]' '[:upper:]')"
dns_auth_secret="$(cut -d':' -f2- <<<"$dns_auth" | cut -d'~' -f2-)"

dns_host_aaaa="$(dig +short AAAA "$dns_hostname" | head -n1)"

[ -d /etc/kaboom ] || mkdir -p /etc/kaboom

umask 266
cat >/etc/kaboom/dns-auth.conf <<CONF
# Managed by apt, please use dpkg-reconfigure kaboom-api to modify
dns_rfc2136_server = $dns_host_aaaa
dns_rfc2136_port = 53
dns_rfc2136_name = $dns_auth_keyname
dns_rfc2136_secret = $dns_auth_secret
dns_rfc2136_algorithm = $dns_auth_algorithm
CONF
umask 022

certbot_account_count="$(find /etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/ -maxdepth 1 -mindepth 1 | wc -l)"
if [ "z$certbot_account_count" = "z0" ]; then
certbot register --non-interactive --email "$CERTBOT_EMAIL" --no-eff-email --agree-tos
fi

echo "Checking if SSL certificate already exists"
if [ ! -f "/etc/letsencrypt/live/kaboom-elearning/fullchain.pem" ]; then
echo "Requesting new certificate for $FQDN and *.$FQDN"
certbot certonly --non-interactive --cert-name kaboom-elearning --dns-rfc2136 --dns-rfc2136-credentials /etc/kaboom/dns-auth.conf --domain "$FQDN" --domain "*.$FQDN" --deploy-hook /usr/share/kaboom-api/bin/cert-deploy
if [ $? -eq 0 ]; then
echo "Certificate obtained successfully"
else
echo "Error obtaining certificate"
fi
else
echo "Certificate already exists"
fi

echo "Checking if SSL DHParams file already exists"
if [ ! -f "/etc/kaboom/ssl-dhparams.pem" ]; then
openssl dhparam -out /etc/kaboom/ssl-dhparams.pem 2048
if [ $? -eq 0 ]; then
echo "DHParams generated successfully"
else
echo "Error generating DHParams"
fi
else
echo "DHParams file already exists"
fi

cat >/etc/nginx/sites-available/kaboom-elearning <<CONF
server {
root /usr/share/kaboom-api/public;
server_name *.$FQDN;

location / {
proxy_pass http://kaboom_api/;
proxy_set_header Host \$host;
proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto \$scheme;
proxy_buffers 8 32k;
proxy_buffer_size 64k;
client_max_body_size 0;
proxy_redirect off;
proxy_buffering off;
}

listen [::]:443 ssl http2;
listen 443 ssl http2;

ssl_certificate /etc/letsencrypt/live/kaboom-elearning/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/kaboom-elearning/privkey.pem;
ssl_dhparam /etc/kaboom/ssl-dhparams.pem;

ssl_session_cache shared:le_nginx_SSL:10m;
ssl_session_timeout 1440m;
ssl_session_tickets off;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384";
}
CONF

[ -L /etc/nginx/sites-enabled/kaboom-elearning ] || ln -s /etc/nginx/sites-available/kaboom-elearning /etc/nginx/sites-enabled

nginx -q -t && service nginx reload

else
echo "one or more of DNS_AUTHENTICATION, CERTBOT_EMAIL, FQDN are missing, skipping wildcard subdomains SSL certificate setup."
fi

</pre>

==== f. Creating the cert-deploy Deploy Hook ====

The certbot command calls in a <code>cert-deploy</code> file via the --deploy-hook flag. This <code>cert-deploy</code> script, should be created in <code>/usr/share/<PKG_NAME>/bin</code>, and runs after each certificate issuance or renewal.

<pre lang="bash">
#!/bin/bash

set -euo pipefail

if [ "z$RENEWED_LINEAGE" != "z/etc/letsencrypt/live/<CERT_NAME>" ]; then
echo "Unknown certificate renewed, ignoring" 1>&2
exit 1
fi

nginx -q -t && service nginx reload
</pre>

==== g. Final Step: Applying Configuration Changes ====

To complete the setup and ensure all configurations take effect, we need to set the required variables (DNS_AUTHENTICATION, CERTBOT_EMAIL, FQDN), run the following command:
<code>sudo dpkg-reconfigure <PKG_NAME></code>