brent

This article is for those looking for a detailed and straightforward guide on installing Bitwarden on Ubuntu Server 22.04 LTS. Bitwarden is a free open-source password manager with the ability to sync your account information across all devices. In this guide, we will consider the case when you already have a server running Ubuntu Server 22.04 LTS. prerequisites: Docker Engine installed. Instructions can be found here. Docker Compose installed. Instructions for installation here. Please note: that you will need to open the following TCP ports to access your server: TCP port 80 - to receive a free cryptographic certificate through the Let’s Encrypt CA. TCP port 443 - to access the Bitwarden dashboard. gmail app password created Create the password here. First, you need to request an installation ID and installation key to host Bitwarden on your server. You must use a unique ID and key for each Bitwarden installation. Follow the link, enter your email address in the “Admin Email Address” field and click on the “Submit” button. Save the resulting “Installation Id” and “Installation Key”. These values will be required during Bitwarden installation. We connect to the server on which you plan to install Bitwarden. Download the Bitwarden installation script using the command: curl -Lso bitwarden.sh https://go.btwrdn.co/bw-sh Let’s enable the execution of the file “bitwarden.sh” using the command: chmod +x bitwarden.sh Now let’s start the Bitwarden installation using the command: sudo ./bitwarden.sh install Now you need to specify the domain name that you plan to use to access the Bitwarden dashboard. Specify the domain name to access Bitwarden and press the “Enter” button. This tutorial walks you through obtaining a free cryptographic certificate through the Let’s Encrypt CA. Press the “y” button, then “Enter”. We indicate the email address to which Let’s Encrypt will send notifications about the expiration of the certificate and press the “Enter” button. Specify the database name for the Bitwarden instance and press the “Enter” button. Specify the “Installation Id” obtained earlier and press the “Enter” button. We indicate the “Installation Key” obtained earlier and press the “Enter” button. Bitwarden installed successfully. Now let’s start Bitwarden using the command: sudo ./bitwarden.sh start Bitwarden launched successfully. To access the Bitwarden control panel, you need to go from the workstation to the link https://subdomain.domain.com, where subdomain.domain.com is the name of your server. Accordingly, you need to specify the name of your server with Bitwarden installed. Next, you need to register to start using the Bitwarden dashboard. At this point your Bitwarden installation is complete. How to setup the SMTP Server in BitWarden Problem How to setup a Mail Relay in BitWarden? How to setup the SMTP Server in BitWarden? Solution Follow the guide below to configure BitWarden to use outMail as a Internet Mail Relay. This article assumes you are running a self-hosted version of BitWarden and that you have already installed it and its working. In order for BitWarden to send emails via outMail you need to change the SMTP Server settings. This can be achieved by editing the global override environment variables. Edit the file called bwdata/env/global.override.env and change the following lines While in the file it's best to configure the following: globalSettings__disableUserRegistration=true (if you don't want people to register for an account). [email protected] to access the admin console via https://subdomain.domain.com/admin Once settings have been made restart bitward. sudo ./bitwarden.sh restart For more information on the BitWarden global vars please see the documentation - bitwarden.com/help/article/environment-variables

If you try and run an upgrade on your nextcloud instance and it fails. Try the following. 1. Occasionally, files do not show up after a upgrade. A rescan of the files can help: sudo -u www-data php console.php files:scan --all 2. Sometimes, Nextcloud can get stuck in a upgrade if the web based upgrade process is used. This is usually due to the process taking too long and encountering a PHP time-out. Stop the upgrade process this way: sudo -u www-data php occ maintenance:mode --off 3. Sometimes, Nextcloud will return errors after upgrading telling you some indexes are missing. sudo -u www-data php occ db:add-missing-indices 4. Then start the manual process: sudo -u www-data php occ upgrade 5. If this does not work properly, try the repair function: sudo -u www-data php occ maintenance:repair 6. Log back into nextcloud and run the upgrade again.

if you are running multiple vhost in nginx, you may want to change the location of your site logs. in this exercise we have a structure of: /var/www/domain.com/html & /var/www/domain.com/log 1. Create a folder in /var/www/domain.com/log 2. open /etc/nginx/sites-enabled/domain.com 3. Add the access_log and error_log to your vhost file and save the configuration file. server { listen 80; server_name www.domain.com; root /var/www/domain.com/html/; access_log /var/www/domain.com/log/domain.com.access.log; error_log /var/www/domain.com/log/domain.com.error.log; } 4. Reload Nginx server systemctl restart nginx.service 5. Check /var/www/domain.com/log to ensure two log files have been created.

If you are wanting to mount a usb external drive to backup your vm's do the following. 1. Plug your usb external drive into your proxmox server. 2. Create a mount location directory. mkdir /mnt/usb-drive 3. check to see if your usb drive is detected. lsblk 4. mount the drive mount /dev/sdc1 /mnt/usb-drive/ mount /dev/sdb /mnt/wd-external/ 5. Verify the drive has been mounted. df -h 6. Go to datacenter in Proxmox and create new storage.

If you are using let's encrypt for your SSL cert, then you know it expiries every 90 days. If you need to check time remaining on your certs run the following: openssl x509 -noout -dates -in /etc/letsencrypt/live/yourdomain.com/cert.pem

Introduction Let’s Encrypt is a Certificate Authority (CA) that facilitates obtaining and installing free TLS/SSL certificates, thereby enabling encrypted HTTPS on web servers. It streamlines the process by providing a software client, Certbot, that attempts to automate most (if not all) of the required steps. Currently, the entire process of obtaining and installing a certificate is fully automated on both Apache and Nginx. In this guide, you’ll use Certbot to obtain a free SSL certificate for Apache on Ubuntu 22.04, and make sure this certificate is set up to renew automatically. This tutorial uses a separate virtual host file instead of Apache’s default configuration file for setting up the website that will be secured by Let’s Encrypt. We recommend creating new Apache virtual host files for each domain hosted in a server because it helps to avoid common mistakes and maintains the default configuration files as a fallback setup. Prerequisites To follow this tutorial, you will need: One Ubuntu 22.04 server set up with a non-root user with sudo administrative privileges and firewall enabled. You can set this up by following our initial server setup for Ubuntu 22.04 tutorial. A fully registered domain name. This tutorial will use your_domain as an example throughout. An A record with your_domain pointing to your server’s public IP address. An A record with www.your_domain pointing to your server’s public IP address. Step 1 — Installing Certbot To obtain an SSL certificate with Let’s Encrypt, you need to install the Certbot software on your server. You’ll use the default Ubuntu package repositories for that. First, update the local package index: sudo apt update You need two packages: certbot, and python3-certbot-apache. The latter is a plugin that integrates Certbot with Apache, making it possible to automate obtaining a certificate and configuring HTTPS within your web server with a single command: sudo apt install certbot python3-certbot-apache You will be prompted to confirm the installation by pressing Y, then ENTER. Certbot is now installed on your server. In the next step, you’ll verify Apache’s configuration to make sure your virtual host is set appropriately. This will ensure that the certbot client script will be able to detect your domains and reconfigure your web server to use your newly generated SSL certificate automatically. Step 2 — Checking your Apache Virtual Host Configuration To automatically obtain and configure SSL for your web server, Certbot needs to find the correct virtual host within your Apache configuration files. Your server domain name(s) will be retrieved from the ServerName and ServerAlias directives defined within your VirtualHost configuration block. To confirm this is set up, open the virtual host file for your domain using nano or your preferred text editor: sudo nano /etc/apache2/sites-available/your_domain.conf Find the existing ServerName and ServerAlias lines. They should be listed as follows: ... ServerName your_domain ServerAlias www.your_domain ... If you already have your ServerName and ServerAlias set up like this, you can exit your text editor and move on to the next step. If your current virtual host configuration doesn’t match the example, update it accordingly. If you’re using nano, you can exit by pressing CTRL+X, then Y and ENTER to confirm your changes, if any. Then, run the following command to validate your changes: sudo apache2ctl configtest You should receive Syntax OK as a response. If you get an error, reopen the virtual host file and check for any typos or missing characters. Once your configuration file’s syntax is correct, reload Apache so that the changes take effect: sudo systemctl reload apache2 With these changes, Certbot will be able to find the correct VirtualHost block and update it. Next, you’ll update the firewall to allow HTTPS traffic. Step 3 — Allowing HTTPS Through the Firewall If you have the UFW firewall enabled, as recommended by the prerequisite guides, you’ll need to adjust the settings to allow HTTPS traffic. Upon installation, Apache registers a few different UFW application profiles. You can leverage the Apache Full profile to allow both HTTP and HTTPS traffic on your server. To verify what kind of traffic is currently allowed on your server, check the status: sudo ufw status If you followed one of our Apache installation guides, you will have output similar to the following, meaning that only HTTP traffic on port 80 is currently allowed: Output Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Apache ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Apache (v6) ALLOW Anywhere (v6) To allow for HTTPS traffic, allow the “Apache Full” profile: sudo ufw allow 'Apache Full' Then delete the redundant “Apache” profile: sudo ufw delete allow 'Apache' Your status will display as the following: sudo ufw status Output Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Apache Full ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Apache Full (v6) ALLOW Anywhere (v6) You are now ready to run Certbot and obtain your certificates. Step 4 — Obtaining an SSL Certificate Certbot provides a variety of ways to obtain SSL certificates through plugins. The Apache plugin will take care of reconfiguring Apache and reloading the configuration whenever necessary. To use this plugin, run the following: sudo certbot --apache This script will prompt you to answer a series of questions in order to configure your SSL certificate. First, it will ask you for a valid email address. This email will be used for renewal notifications and security notices: Output Saving debug log to /var/log/letsencrypt/letsencrypt.log Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel): you@your_domain After providing a valid email address, press ENTER to proceed to the next step. You will then be prompted to confirm if you agree to Let’s Encrypt terms of service. You can confirm by pressing Y and then ENTER: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Please read the Terms of Service at https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must agree in order to register with the ACME server at https://acme-v02.api.letsencrypt.org/directory - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (Y)es/(N)o: Y Next, you’ll be asked if you would like to share your email with the Electronic Frontier Foundation to receive news and other information. If you do not want to subscribe to their content, write N. Otherwise, write Y then press ENTER to proceed to the next step: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Would you be willing to share your email address with the Electronic Frontier Foundation, a founding partner of the Let's Encrypt project and the non-profit organization that develops Certbot? We'd like to send you email about our work encrypting the web, EFF news, campaigns, and ways to support digital freedom. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (Y)es/(N)o: N The next step will prompt you to inform Certbot of which domains you’d like to activate HTTPS for. The listed domain names are automatically obtained from your Apache virtual host configuration, so it’s important to make sure you have the correct ServerName and ServerAlias settings configured in your virtual host. If you’d like to enable HTTPS for all listed domain names (recommended), you can leave the prompt blank and press ENTER to proceed. Otherwise, select the domains you want to enable HTTPS for by listing each appropriate number, separated by commas and/ or spaces, then press ENTER: Which names would you like to activate HTTPS for? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1: your_domain 2: www.your_domain - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate numbers separated by commas and/or spaces, or leave input blank to select all options shown (Enter 'c' to cancel): After this step, Certbot’s configuration is finished, and you will be presented with the final remarks about your new certificate and where to locate the generated files: Output Successfully received certificate. Certificate is saved at: /etc/letsencrypt/live/your_domain/fullchain.pem Key is saved at: /etc/letsencrypt/live/your_domain/privkey.pem This certificate expires on 2022-07-10. These files will be updated when the certificate renews. Certbot has set up a scheduled task to automatically renew this certificate in the background. Deploying certificate Successfully deployed certificate for your_domain to /etc/apache2/sites-available/your_domain-le-ssl.conf Successfully deployed certificate for www.your_domain.com to /etc/apache2/sites-available/your_domain-le-ssl.conf Congratulations! You have successfully enabled HTTPS on https:/your_domain and https://www.your_domain.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If you like Certbot, please consider supporting our work by: * Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate * Donating to EFF: https://eff.org/donate-le - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Your certificate is now installed and loaded into Apache’s configuration. Try reloading your website using https:// and notice your browser’s security indicator. It should indicate that your site is properly secured, typically by a lock icon in the address bar. You can use the SSL Labs Server Test to verify your certificate’s grade and obtain detailed information about it, from the perspective of an external service. In the next and final step, you’ll test the auto-renewal feature of Certbot, which guarantees that your certificate will be renewed automatically before the expiration date. Step 5 — Verifying Certbot Auto-Renewal Let’s Encrypt’s certificates are only valid for ninety days. This is to encourage users to automate their certificate renewal process, as well as to ensure that misused certificates or stolen keys will expire sooner rather than later. The certbot package you installed takes care of renewals by including a renew script to /etc/cron.d, which is managed by a systemctl service called certbot.timer. This script runs twice a day and will automatically renew any certificate that’s within thirty days of expiration. To check the status of this service and make sure it’s active, run the following: sudo systemctl status certbot.timer Your output will be similar to the following: Output ● certbot.timer - Run certbot twice daily Loaded: loaded (/lib/systemd/system/certbot.timer; enabled; vendor preset:> Active: active (waiting) since Mon 2022-04-11 20:52:46 UTC; 4min 3s ago Trigger: Tue 2022-04-12 00:56:55 UTC; 4h 0min left Triggers: ● certbot.service Apr 11 20:52:46 jammy-encrypt systemd[1]: Started Run certbot twice daily. To test the renewal process, you can do a dry run with certbot: sudo certbot renew --dry-run Output Saving debug log to /var/log/letsencrypt/letsencrypt.log - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Processing /etc/letsencrypt/renewal/your_domain.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Account registered. Simulating renewal of an existing certificate for your_domain and www.your_domain.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Congratulations, all simulated renewals succeeded: /etc/letsencrypt/live/your_domain/fullchain.pem (success) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If you don’t receive any errors, you’re all set. When necessary, Certbot will renew your certificates and reload Apache to pick up the changes. If the automated renewal process ever fails, Let’s Encrypt will send a message to the email you specified, warning you when your certificate is about to expire. Conclusion In this tutorial, you installed the Let’s Encrypt client certbot, configured and installed an SSL certificate for your domain, and confirmed that Certbot’s automatic renewal service is active within systemctl. If you have further questions about using Certbot, their documentation is a good place to start.

Let’s Encrypt is a non-profit certificate authority run by Internet Security Research Group that provides X.509 certificates for Transport Layer Security encryption at no charge. Steps on How to Setup Nginx with Let’s Encrypt on Ubuntu 22.04: Step 1: Install Certbot Step 2: Check Nginx Configuration Step 3: Allowing HTTPS Through the Firewall Step 4: Get Free SSL/TLS Certificate Step 5: Enable Automatic Certificate Renewal Step 6: Conclusion Step 1: Install Certbot Firstly, We are going to install certbot. To install run the following command line. sudo apt update sudo apt install certbot python3-certbot-nginx Step 2: Check Nginx Configuration Run the following command on the command line to check that it is set up correctly. sudo nano /etc/nginx/sites-available/example.com You want to include a domain name with and without www. So enter the following command. server_name example.com www.example.com Step 3: Allowing HTTPS Through the Firewall So now, by the following command check the firewall status. sudo ufw status Allow Nginx full profile and type the following command to delete unnecessary Nginx HTTP profile allowance. sudo ufw allow 'Nginx Full' sudo ufw delete allow 'Nginx HTTP' Step 4: Get Free SSL/TLS Certificate Now, execute the following command on command line to get free ssl/tls certificate. sudo certbot --nginx -d example.com -d www.example.com Step 5: Enable Automatic Certificate Renewal Use the following command on the command line to create automatic renewal: sudo systemctl status snap.certbot.renew.service To test the renewal process, Use the dry command with certbot: sudo certbot renew --dry-run Step 6: Conclusion You have now setup Nginx with Let’s Encrypt on Ubuntu 22.04

Step 1 – Installing the Nginx Web Server To display web pages to site visitors, you’re going to employ Nginx, a high-performance web server. You’ll use the APT package manager to obtain this software. Since this is your first time using apt for this session, start off by updating your server’s package index: sudo apt update Following that, run apt install to install Nginx: sudo apt install nginx When prompted, press Y and ENTER to confirm that you want to install Nginx. Once the installation is finished, the Nginx web server will be active and running on your Ubuntu 22.04 server. If you have the ufw firewall enabled, as recommended in our initial server setup guide, you will need to allow connections to Nginx. Nginx registers a few different UFW application profiles upon installation. To check which UFW profiles are available, run: sudo ufw app list Output Available applications: Nginx Full Nginx HTTP Nginx HTTPS OpenSSH t is recommended that you enable the most restrictive profile that will still allow the traffic you need. Since you haven’t configured SSL for your server in this guide, you will only need to allow regular HTTP traffic on port 80. Enable this by running the following: sudo ufw allow 'Nginx HTTP' You can verify the change by checking the status: sudo ufw status This output displays that HTTP traffic is now allowed: Output Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Nginx HTTP ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Nginx HTTP (v6) ALLOW Anywhere (v6) With the new firewall rule added, you can test if the server is up and running by accessing your server’s domain name or public IP address in your web browser. If you do not have a domain name pointed at your server and you do not know your server’s public IP address, you can find it by running either of the following commands: ip addr show hostname -I This will print out a few IP addresses. You can try each of them in turn in your web browser. As an alternative, you can check which IP address is accessible, as viewed from other locations on the internet: curl -4 icanhazip.com Write the address that you receive in your web browser and it will take you to Nginx’s default landing page: http://server_domain_or_IP Step 2 — Installing MySQL Now that you have a web server up and running, you need to install the database system to store and manage data for your site. MySQL is a popular database management system used within PHP environments. Again, use apt to acquire and install this software: sudo apt install mysql-server When prompted, confirm installation by pressing Y, and then ENTER. When the installation is finished, it’s recommended that you run a security script that comes pre-installed with MySQL. This script will remove some insecure default settings and lock down access to your database system. Start the interactive script by running the following command: sudo mysql_secure_installation You will be prompted with a question asking if you want to configure the VALIDATE PASSWORD PLUGIN. Note: Enabling this feature is something of a judgment call. If enabled, passwords which don’t match the specified criteria will be rejected by MySQL with an error. It is safe to leave validation disabled, but you should always use strong, unique passwords for database credentials. Answer Y for yes, or anything else to continue without enabling: Output VALIDATE PASSWORD COMPONENT can be used to test passwords and improve security. It checks the strength of password and allows the users to set only those passwords which are secure enough. Would you like to setup VALIDATE PASSWORD component? Press y|Y for Yes, any other key for No: If you answer “yes”, you’ll be asked to select a level of password validation. Keep in mind that if you enter 2 for the strongest level, you will receive errors when attempting to set any password that does not contain numbers, upper and lowercase letters, and special characters: Output There are three levels of password validation policy: LOW Length >= 8 MEDIUM Length >= 8, numeric, mixed case, and special characters STRONG Length >= 8, numeric, mixed case, special characters and dictionary file Please enter 0 = LOW, 1 = MEDIUM and 2 = STRONG: 1 Regardless of whether you chose to set up the VALIDATE PASSWORD PLUGIN, your server will ask you to select and confirm a password for the MySQL root user. This is not to be confused with the system root. The database root user is an administrative user with full privileges over the database system. Even though the default authentication method for the MySQL root user dispenses the use of a password, even when one is set, you should define a strong password here as an additional safety measure. We’ll talk about this in a moment. If you enabled password validation, you’ll be shown the password strength for the root password you entered and your server will ask if you want to continue with that password. If you are happy with your current password, press Y for “yes” at the prompt: Output Estimated strength of the password: 100 Do you wish to continue with the password provided?(Press y|Y for Yes, any other key for No) : y For the rest of the questions, press Y and hit the ENTER key at each prompt. This will remove some anonymous users and the test database, disable remote root logins, and load these new rules so that MySQL immediately respects the changes you have made. When you’re finished, test if you’re able to log in to the MySQL console: sudo mysql This will connect to the MySQL server as the administrative database user root, which is inferred by the use of sudo when running this command. You should receive the following output: Output Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 10 Server version: 8.0.28-0ubuntu4 (Ubuntu) Copyright (c) 2000, 2022, Oracle and/or its affiliates. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> To exit the MySQL console,write the following: exit Notice that you didn’t need to provide a password to connect as the root user, even though you have defined one when running the mysql_secure_installation script. This is because, when installed on Ubuntu, the default authentication method for the administrative MySQL user is auth_socket, rather than with a method that uses a password. This may seem like a security concern at first, but it makes the database server more secure since the only users allowed to log in as the root MySQL user are the system users with sudo privileges connecting from the console or through an application running with the same privileges. In practical terms, that means you won’t be able to use the administrative database root user to connect from your PHP application. For increased security, it’s best to have dedicated user accounts with less expansive privileges set up for every database, especially if you plan on having multiple databases hosted on your server. Note: Certain older releases of the native MySQL PHP library mysqlnd don’t support caching_sha2_authentication, the default authentication method for created users MySQL 8. For that reason, when creating database users for PHP applications on MySQL 8, you may need to make sure they’re configured to use mysql_native_password instead. We’ll demonstrate how to do that in Step 6. Your MySQL server is now installed and secured. Next, you’ll install PHP, the final component in the LEMP stack. Step 3 – Installing PHP You have Nginx installed to serve your content and MySQL installed to store and manage your data. Now you can install PHP to process code and generate dynamic content for the web server. While Apache embeds the PHP interpreter in each request, Nginx requires an external program to handle PHP processing and act as a bridge between the PHP interpreter itself and the web server. This allows for better overall performance in most PHP-based websites, but it requires additional configuration. You’ll need to install php8.1-fpm, which stands for “PHP fastCGI process manager” and uses the current version of PHP (at the time of writing), to tell Nginx to pass PHP requests to this software for processing. Additionally, you’ll need php-mysql, a PHP module that allows PHP to communicate with MySQL-based databases. Core PHP packages will automatically be installed as dependencies. To install the php8.1-fpm and php-mysql packages, run: sudo apt install php8.1-fpm php-mysql When prompted, press Y and ENTER to confirm the installation. You now have your PHP components installed. Next, you’ll configure Nginx to use them. Step 4 — Configuring Nginx to Use the PHP Processor When using the Nginx web server, we can create server blocks (similar to virtual hosts in Apache) to encapsulate configuration details and host more than one domain on a single server. In this guide, we’ll use your_domain as an example domain name. On Ubuntu 22.04, Nginx has one server block enabled by default and is configured to serve documents out of a directory at /var/www/html. While this works well for a single site, it can become difficult to manage if you are hosting multiple sites. Instead of modifying /var/www/html, we’ll create a directory structure within /var/www for the your_domain website, leaving /var/www/html in place as the default directory to be served if a client request doesn’t match any other sites. Create the root web directory for your_domain as follows: sudo mkdir /var/www/your_domain Next, assign ownership of the directory with the $USER environment variable, which will reference your current system user: sudo chown -R $USER:$USER /var/www/your_domain Then, open a new configuration file in Nginx’s sites-available directory using your preferred command-line editor. Here, we’ll use nano: sudo nano /etc/nginx/sites-available/your_domain This will create a new blank file. Insert the following bare-bones configuration: server { listen 80; server_name your_domain www.your_domain; root /var/www/your_domain; index index.html index.htm index.php; location / { try_files $uri $uri/ =404; } location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/var/run/php/php8.1-fpm.sock; } location ~ /\.ht { deny all; } } Here’s what each of these directives and location blocks do: listen — Defines what port Nginx will listen on. In this case, it will listen on port 80, the default port for HTTP. root — Defines the document root where the files served by this website are stored. index — Defines in which order Nginx will prioritize index files for this website. It is a common practice to list index.html files with higher precedence than index.php files to allow for quickly setting up a maintenance landing page in PHP applications. You can adjust these settings to better suit your application needs. server_name — Defines which domain names and/or IP addresses this server block should respond for. Point this directive to your server’s domain name or public IP address. location / — The first location block includes a try_files directive, which checks for the existence of files or directories matching a URL request. If Nginx cannot find the appropriate resource, it will return a 404 error. location ~ \.php$ — This location block handles the actual PHP processing by pointing Nginx to the fastcgi-php.conf configuration file and the php8.1-fpm.sock file, which declares what socket is associated with php8.1-fpm. location ~ /\.ht — The last location block deals with .htaccess files, which Nginx does not process. By adding the deny all directive, if any .htaccess files happen to find their way into the document root, they will not be served to visitors. When you’re done editing, save and close the file. If you’re using nano, you can do so by pressing CTRL+X and then Y and ENTER to confirm. Activate your configuration by linking to the configuration file from Nginx’s sites-enabled directory: sudo ln -s /etc/nginx/sites-available/your_domain /etc/nginx/sites-enabled/ Then, unlink the default configuration file from the /sites-enabled/ directory: sudo unlink /etc/nginx/sites-enabled/default Note: If you ever need to restore the default configuration, you can do so by recreating the symbolic link, like the following: sudo ln -s /etc/nginx/sites-available/default /etc/nginx/sites-enabled/ This will tell Nginx to use the configuration next time it is reloaded. You can test your configuration for syntax errors by running the following: sudo nginx -t If any errors are reported, go back to your configuration file to review its contents before continuing. When you are ready, reload Nginx to apply the changes: sudo systemctl reload nginx Your new website is now active, but the web root /var/www/your_domain is still empty. Create an index.html file in that location so that you can test that your new server block works as expected: nano /var/www/your_domain/index.html Include the following content in this file: <html> <head> <title>your_domain website</title> </head> <body> <h1>Hello World!</h1> <p>This is the landing page of <strong>your_domain</strong>.</p> </body> </html> Now go to your browser and access your server’s domain name or IP address, as listed within the server_name directive in your server block configuration file: http://server_domain_or_IP You’ll receive a page like the following: If you receive this page, it means your Nginx server block is working as expected. You can leave this file in place as a temporary landing page for your application until you set up an index.php file to replace it. Once you do that, remember to remove or rename the index.html file from your document root, as it would take precedence over an index.php file by default. Your LEMP stack is now fully configured. In the next step, you’ll create a PHP script to test that Nginx is in fact able to handle .php files within your newly configured website. Step 5 –Testing PHP with Nginx Your LEMP stack should now be completely set up. You can test it to validate that Nginx can correctly hand .php files off to your PHP processor. You can do this by creating a test PHP file in your document root. Open a new file called info.php within your document root in your preferred text editor: nano /var/www/your_domain/info.php Add the following lines into the new file. This is valid PHP code that will return information about your server: <?php phpinfo(); When you are finished, save and close the file. You can now access this page in your web browser by visiting the domain name or public IP address you’ve set up in your Nginx configuration file, followed by /info.php: You will receive a web page containing detailed information about your server: After checking the relevant information about your PHP server through that page, it’s best to remove the file you created as it contains sensitive information about your PHP environment and your Ubuntu server. You can use rm to remove that file: sudo rm /var/www/your_domain/info.php You have successfully installed LEMP

Cron Using the operating system cron feature is the preferred method for executing regular tasks. This method enables the execution of scheduled jobs without the inherent limitations the Web server might have. To run a cron job on a *nix system, every 5 minutes, under the default Web server user (often, www-data or wwwrun), you must set up the following cron job to call the cron.php script: sudo crontab -e -u www-data */5 * * * * php -f /var/www/cloud.kc-linux.com/html/cron.php */5 * * * * /usr/bin/php /var/www/cloud.kc-linux.com/html/occ preview:pre-generate > /dev/null 2>&1 You can verify if the cron job has been added and scheduled by executing: crontab -u www-data -l If Cron isn't working and you are getting an error under nextcloud basic setting about site not running back ground processes. go to /etc/php/{{ php_version }}/mods-available/apcu.ini and add the below. apc.enable_cli=1 Once added run: sudo -u www-data php -f /var/www/nexcloud/cron.php If it completes without errors it's working.

DEB-based distros (Ubuntu, etc.) To enable the Plex Media Server repository on Ubuntu only a few terminal commands are required. From a terminal window run the following two commands: echo deb https://downloads.plex.tv/repo/deb public main | sudo tee /etc/apt/sources.list.d/plexmediaserver.list wget https://downloads.plex.tv/plex-keys/PlexSign.key cat PlexSign.key | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/PlexSigkey.gpg After that, it’s just a matter of running the normal sudo apt-get update and the Plex Media Server repo will be enabled on the OS.

You can remove the PPA from the sources list where these PPAs are stored. PPA repositories are store in the form of PPA_Name.list. Use the following command to see all the PPAs added in your system: ls /etc/apt/sources.list.d

Installation instructions are located https://linuxiac.com/nala-apt-command-frontend/

Run the following commands to identify what your DNS settings are. Ubuntu 22.04 resolvectl status | grep "DNS Server" -A2 or Ubuntu 20.04 or Older systemd-resolve --status | grep 'DNS Servers' -A2

Open super user bash sudo bash Go to the NextCloud folder: cd /var/www/nextcloud Run the following command: sudo -u www-data php occ db:add-missing-indices And finally the prompt should show something like this: Check indices of the share table. Adding additional parent index to the share table, this can take some time… Share table updated successfully. Adding additional mtime index to the filecache table, this can take some time… Filecache table updated successfully. And that's all, the problem should being fixed

To remove the “You do not have a valid subscription for this server” popup message while logging in, run the command bellow. You’ll need to SSH to your Proxmox server or use the node console through the PVE web interface. If you have issues and need to revert changes please check the instructions at the bottom of this page. When you update your Proxmox server and the update includes the proxmox-widget-toolkit package, you’ll need to complete this modification again. This modification works with versions 5.1 and newer, tested up to the version shown in the title. Run the following one line command and then clear your browser cache (depending on the browser you may need to open a new tab or restart the browser): sed -Ezi.bak "s/(Ext.Msg.show\(\{\s+title: gettext\('No valid sub)/void\(\{ \/\/\1/g" /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js && systemctl restart pveproxy.service Manual Steps Here are alternative step by step instructions so you can understand what the above command is doing: 1. Change to working directory cd /usr/share/javascript/proxmox-widget-toolkit 2. Make a backup cp proxmoxlib.js proxmoxlib.js.bak 3. Edit the file nano proxmoxlib.js 4. Locate the following code (Use ctrl+w in nano and search for “No valid subscription”) Ext.Msg.show({ title: gettext('No valid subscription'), 5. Replace “Ext.Msg.show” with “void” void({ //Ext.Msg.show({ title: gettext('No valid subscription'), 6. Restart the Proxmox web service (also be sure to clear your browser cache, depending on the browser you may need to open a new tab or restart the browser) systemctl restart pveproxy.service Additional Notes You can quickly check if the change has been made: grep -n -B 1 'No valid sub' proxmoxlib.js You have three options to revert the changes: Manually edit proxmoxlib.js to undo the changes you made Restore the backup file you created from the proxmox-widget-toolkit directory: mv proxmoxlib.js.bak proxmoxlib.js Reinstall the proxmox-widget-toolkit package from the repository: apt-get install --reinstall proxmox-widget-toolkit

If you remove a server and it errors saying storage "images" or what ever you name your storage doesn't exist. do the following. Navigate to your storage and ensure the image is gone. Check your storage: My storage location is /mnt/wd-external/images/images Next navigate to /etc/pve/qemu-server remove the server UUID.conf file.

If you are running a webserver, Database, or plex server you might find that your memory is at 90%+ all the time. Here is how to clear it up. 1. create a file at /usr/local/bin. I am calling it free-memory but you can call the file what ever you want. sudo nano /usr/local/bin/free-memory 3. add the command then save and close. free -h && sudo sysctl -w vm.drop_caches=3 && sudo sync && echo 3 | sudo tee /proc/sys/vm/drop_caches && free -h 2. change the permissions of the script. sudo chmod 555 free-memory 4. Creating a cron job. sudo contrab -e 5. I want to run mine every minute. Change this to your needs. * * * * * /usr/local/bin/free-memory 6. check your server after a minute. you should see your memory usage change.

Accessing a Gmail Account from Nextcloud Due to Google's security policies, accessing your Gmail account from Nextcloud requires additional steps. If you use two factor authentication, you'll need to generate an app password: Visit https://myaccount.google.com/apppasswords from a web browser At the bottom of the page, click the drop-down box labeled "Select app" Choose the option, "Other (Custom name)" Enter a descriptive name, such as "Nextcloud Mail" Click "Generate" Go back to Nextcloud (Mail/Rainloop), and enter your e-mail address and the app password you just generated Your Gmail account should now be accessible from within Nextcloud If you are not using two factor authentication, you'll need to allow "Less Secure Apps": Visit https://myaccount.google.com/lesssecureapps Toggle the radio button "Allow less secure apps" to the "ON" position Go back to Nextcloud (Mail/Rainloop), and enter your e-mail address and Google password Your Gmail account should now be accessible from within Nextcloud

The Issue We want to disable snapd service on system startup/prevent snapd service startup automatically on system boot on Ubuntu or remove Snap completely. 1 Disable snap services 1.1 Bring up the terminal or login via SSH 1.2 Execute following commands to disable snap services sudo systemctl disable snapd.service sudo systemctl disable snapd.socket sudo systemctl disable snapd.seeded sudo systemctl disable snapd.snap-repair.timer 1.3 Restart the system sudo reboot 1.4 Now the snap service will not start on system startup 2 Removing Snap To uninstall snap (If necessary), we need to make sure snap is not used at all. If we want to uninstall/remove snap just follow the below steps 2.1 List all snaps snap list 2.2 If there is any installed snap pckage e.g. bashtop, remove all of them one by one sudo snap remove bashtop 2.3 Find the snap core service directory ID df From the output, under the “Mounted on” column, find the ones with “/snap/core/xxxx” 2.4 Unmount the snap core service sudo umount /snap/core/xxxx 2.5 Remove all snapd package sudo apt purge snapd 2.6 Remove all directories (If necessary), be careful with the rm command, we will lose data if done incorrectly rm -rf ~/snap sudo rm -rf /snap sudo rm -rf /var/snap sudo rm -rf /var/lib/snapd

1: Set your user as the owner chown -R joe /var/www/your-website.com/ This command sets joe as the owner of every file and folder inside the directory (-R stands for recursive). 2: set the web server as the group owner chgrp -R www-data /var/www/your-website.com/ This command sets www-data as the group owner of every file and folder inside the directory. Recursive mode, as above. 3: 750 permissions for everything chmod -R 750 /var/www/your-website.com/ The third command sets the permissions: read, write and execute (7) for the owner (i.e, you), read and execute (5) for the group owner (i.e, the web server0, zero permissions at all (0) for others. Once again this is done on every file and folder in the directory, recursively. 4: new files and folder inherit group ownership from parent folder chmod g+s /var/www/your-website.com/ The last command makes all files/folders created within the directory to automatically take on the group ownership of the parent folder, that is your web server. The S flags is a special mode that represents the setuid/setgid. In simple words, new files and directories created by the web server will have the same group ownership of your-website.com/ folder, which we set to www-data with the second command. When the web server needs to write If you have folders that need to be writable by the web server, you can just modify the permission values for the group owner so that www-data has write access. Run this command on each writable folder: chmod g+w /var/www/your-website.com/<writable-folder> For security reasons apply this only where necessary and not on the whole website directory.

APCu APCu is a data cache, and it is available in most Linux distributions. On Red Hat/CentOS/Fedora systems install php-pecl-apcu. On Debian/Ubuntu/Mint systems install php-apcu. After restarting your Web server, add this line to your config.php file: 'memcache.local' => '\OC\Memcache\APCu', Refresh your Nextcloud admin page, and the cache warning should disappear.

To enable preview for files in nextcloud, you need to install “Preview Generator” from next cloud app store https://apps.nextcloud.com/apps/previewgenerator To install login to nextcloud as admin. From right drop down menu, click + Apps link. Once on Apps page, you can use the search button on right side to search for "Preview Generator" and install it. You need to install some additional software, on ubuntu/debian install it with sudo apt install libreoffice ffmpeg imagemagick ghostscript Now edit config/config.php file of your nextcloud installation, add following code 'enable_previews' => true, 'preview_libreoffice_path' => '/usr/bin/libreoffice', 'enabledPreviewProviders' => array ( 0 => 'OC\\Preview\\TXT', 1 => 'OC\\Preview\\MarkDown', 2 => 'OC\\Preview\\OpenDocument', 3 => 'OC\\Preview\\PDF', 4 => 'OC\\Preview\\MSOffice2003', 5 => 'OC\\Preview\\MSOfficeDoc', 6 => 'OC\\Preview\\PDF', 7 => 'OC\\Preview\\Image', 8 => 'OC\\Preview\\Photoshop', 9 => 'OC\\Preview\\TIFF', 10 => 'OC\\Preview\\SVG', 11 => 'OC\\Preview\\Font', 12 => 'OC\\Preview\\MP3', 13 => 'OC\\Preview\\Movie', 14 => 'OC\\Preview\\MKV', 15 => 'OC\\Preview\\MP4', 16 => 'OC\\Preview\\AVI', ), For more info on configuration, check nextcloud documenation. Generate Preview for existing files Lets generate thumbnail for existing files, for this, I enabled shell access for www-data so preview files have proper file ownership (not owned by root). chsh --shell /bin/bash www-data Now change to www-data user su - www-data Now run: (Without www-data) sudo -u www-data php /var/www/cloud.kc-linux.com/html/occ preview:generate-all -vvv or (with switching to www-data user) /usr/bin/php /var/www/nextcloud/occ preview:generate-all -vvv Autogenerate Previews for new files set a cronjob as user www-data crontab -e -u www-data */5 * * * * /usr/bin/php /var/www/nextcloud/occ preview:pre-generate > /dev/null 2>&1

Letsencrypt Auto Renew Testing: Though this part is optional but I recommand you to test your auto-renew cron script for errors. It will be a disaster if your Letsencrypt Certificate does not renew before expire due to some error. Basic Testing using --dry-run: For error checking we’ll perform certbot renew --dry-run or path/location/certbot-auto renew --dry-run ——- a process in which the auto-renew script will be executed without actually renewing the certificates. Execute the following lines on your Linux terminal, sudo -i certbot renew --dry-run && apache-restart-command testing using --force-renew In this advance testing section we’ll simulate the letsencrypt auto certificate renewal process by using –force-renew command. As you already know that the certbot renew command only take action if your certificate has less than 30 days. But if we use it with “–force-renew” command then your certificate get renewed immediately. Remember that, you only can renew 5 certificates per week for a particular domain or subdomain. Note the date of your current certificate To view the current expire date of your let’s encrypt certificate, execute the following command on your terminal. sudo openssl x509 -noout -dates -in /etc/letsencrypt/live/your-domain-name/fullchain.pem Check if renewal was successful Now, Lets again check the let’s encrypt certificate’s expire date, sudo openssl x509 -noout -dates -in /etc/letsencrypt/live/your-domain-name/fullchain.pem

Node exporter is the best way to collect all the Linux server related metrics and statistics for monitoring. Monitor Linux Servers Using Prometheus In this guide, you will learn how to setup Prometheus node exporter on a Linux server to export all node level metrics to the Prometheus server. Before You Begin Prometheus Node Exporter needs Prometheus server to be up and running. If you would like to setup Prometheus, please see the Port 9100 opened in server firewall as Prometheus reads metrics on this port. Setup Node Exporter Binary Step 1: Download the latest node exporter package. You should check the Prometheus downloads section for the latest version and update this command to get that package. wget https://github.com/prometheus/node_exporter/releases/download/v1.3.1/node_exporter-1.3.1.linux-amd64.tar.gz Step 2: Unpack the tarball tar -xvf node_exporter-0.18.1.linux-amd64.tar.gz Step 3: Move the node export binary to /usr/local/bin sudo mv node_exporter-0.18.1.linux-amd64/node_exporter /usr/local/bin/ Create a Custom Node Exporter Service Step 1: Create a node_exporter user to run the node exporter service. sudo useradd -rs /bin/false node_exporter Step 2: Create a node_exporter service file under systemd. sudo vi /etc/systemd/system/node_exporter.service Step 3: Add the following service file content to the service file and save it. [Unit] Description=Node Exporter After=network.target [Service] User=node_exporter Group=node_exporter Type=simple ExecStart=/usr/local/bin/node_exporter [Install] WantedBy=multi-user.target Step 4: Reload the system daemon and star the node exporter service. sudo systemctl daemon-reload sudo systemctl start node_exporter Step 5: check the node exporter status to make sure it is running in the active state. sudo systemctl status node_exporter Step 6: Enable the node exporter service to the system startup. sudo systemctl enable node_exporter Now, node exporter would be exporting metrics on port 9100. You can see all the server metrics by visiting your server URL on /metrics as shown below. http://<server-IP>:9100/metrics Configure the Server as Target on Prometheus Server Now that we have the node exporter up and running on the server, we have to add this server a target on the Prometheus server configuration. Note: This configuration should be done on the Prometheus server. Step 1: Login to the Prometheus server and open the prometheus.yml file. sudo vi /etc/prometheus/prometheus.yml Step 2: Under the scrape config section add the node exporter target as shown below. Change 10.142.0.3 with your server IP where you have setup node exporter. Job name can be your server hostname or IP for identification purposes. - job_name: 'node_exporter_metrics' scrape_interval: 5s static_configs: - targets: ['10.142.0.3:9100'] Step 3: Restart the prometheus service for the configuration changes to take place. sudo systemctl restart prometheus Now, if you check the target in prometheus web UI (http://<prometheus-IP>:9090/targets) , you will be able to see the status as shown below. Also, you can use the Prometheus expression browser to query for node related metrics. Following are the few key node metrics you can use to find its statistics. node_memory_MemFree_bytes node_cpu_seconds_total node_filesystem_avail_bytes rate(node_cpu_seconds_total{mode="system"}[1m]) rate(node_network_receive_bytes_total[1m])

INSTALL PHP 7.4 1. Install epel repo and remi repo # dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm -y # dnf install https://rpms.remirepo.net/enterprise/remi-release-8.rpm -y 2. Check php module list and Install PHP7.4 # dnf module list php # dnf module enable php:remi-7.4 -y 3. Install PHP and the Extensions # dnf install php php-cli php-common php-json php-xml php-mbstring php-mysqli php-zip php-intl Disable SElinux 1. in order to install PI-Hole you need to disable SElinux /etc/selinux/config 2. reboot the server. Disable Firewall (optional) 1. Disable the Firewall or configure firewall for Pi-hole. sudo systemctl stop firewalld sudo systemctl disable firewalld INSTALL PI-HOLE 1 . Download Install Pi-hole # git clone --depth 1 https://github.com/pi-hole/pi-hole.git Pi-hole # cd "Pi-hole/automated install/" # sed -i "s/lighttpd\slighttpd-fastcgi//" basic-install.sh # chmod +x basic-install.sh # ./basic-install.sh Setting up Pi-hole as a recursive DNS server solution sudo dnf install unbound 1. backup file /etc/unbound/unbound.conf mv /etc/unbound/unbound.conf /etc/unbound/unbound.conf.bak 3. Create a new unbound.conf file nano /etc/unbound/unbound.conf 4. Add the following line and save. include: "/etc/unbound/unbound.conf.d/*.conf" 5. Create /etc/unbound/unbound.conf.d/pi-hole.conf: server: # If no logfile is specified, syslog is used # logfile: "/var/log/unbound/unbound.log" verbosity: 0 interface: 127.0.0.1 port: 5335 do-ip4: yes do-udp: yes do-tcp: yes # May be set to yes if you have IPv6 connectivity do-ip6: no # You want to leave this to no unless you have *native* IPv6. With 6to4 and # Terredo tunnels your web browser should favor IPv4 for the same reasons prefer-ip6: no # Use this only when you downloaded the list of primary root servers! # If you use the default dns-root-data package, unbound will find it automatically #root-hints: "/var/lib/unbound/root.hints" # Trust glue only if it is within the server's authority harden-glue: yes # Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS harden-dnssec-stripped: yes # Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes # see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details use-caps-for-id: no # Reduce EDNS reassembly buffer size. # IP fragmentation is unreliable on the Internet today, and can cause # transmission failures when large DNS messages are sent via UDP. Even # when fragmentation does work, it may not be secure; it is theoretically # possible to spoof parts of a fragmented DNS message, without easy # detection at the receiving end. Recently, there was an excellent study # >>> Defragmenting DNS - Determining the optimal maximum UDP response size for DNS <<< # by Axel Koolhaas, and Tjeerd Slokker (https://indico.dns-oarc.net/event/36/contributions/776/) # in collaboration with NLnet Labs explored DNS using real world data from the # the RIPE Atlas probes and the researchers suggested different values for # IPv4 and IPv6 and in different scenarios. They advise that servers should # be configured to limit DNS messages sent over UDP to a size that will not # trigger fragmentation on typical network links. DNS servers can switch # from UDP to TCP when a DNS response is too big to fit in this limited # buffer size. This value has also been suggested in DNS Flag Day 2020. edns-buffer-size: 1232 # Perform prefetching of close to expired message cache entries # This only applies to domains that have been frequently queried prefetch: yes # One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine, it should be unnecessary to seek performance enhancement by increasing num-threads above 1. num-threads: 1 # Ensure kernel buffer is large enough to not lose messages in traffic spikes so-rcvbuf: 1m # Ensure privacy of local IP ranges private-address: 192.168.0.0/16 private-address: 169.254.0.0/16 private-address: 172.16.0.0/12 private-address: 10.0.0.0/8 private-address: fd00::/8 private-address: fe80::/10 Start your local recursive server and test that it's operational: sudo service unbound restart dig pi-hole.net @127.0.0.1 -p 5335 The first query may be quite slow, but subsequent queries, also to other domains under the same TLD, should be fairly quick. You should also consider adding edns-packet-max=1232 to a config file like /etc/dnsmasq.d/99-edns.conf to signal FTL to adhere to this limit. Test validation¶ You can test DNSSEC validation using dig sigfail.verteiltesysteme.net @127.0.0.1 -p 5335 dig sigok.verteiltesysteme.net @127.0.0.1 -p 5335 The first command should give a status report of SERVFAIL and no IP address. The second should give NOERROR plus an IP address. Configure Pi-hole¶ Finally, configure Pi-hole to use your recursive DNS server by specifying 127.0.0.1#5335 as the Custom DNS (IPv4): (don't forget to hit Return or click on Save) Disable resolvconf for unbound (optional) The unbound package can come with a systemd service called unbound-resolvconf.service and default enabled. It instructs resolvconf to write unbound's own DNS service at nameserver 127.0.0.1 , but without the 5335 port, into the file /etc/resolv.conf. That /etc/resolv.conf file is used by local services/processes to determine DNS servers configured. If you configured /etc/dhcpcd.conf with a static domain_name_servers= line, these DNS server(s) will be ignored/overruled by this service. To check if this service is enabled for your distribution, run below one and take note of the Active line. It will show either active or inactive or it might not even be installed resulting in a could not be found message: sudo systemctl status unbound-resolvconf.service To disable the service if so desire, run below two: sudo systemctl disable unbound-resolvconf.service sudo systemctl stop unbound-resolvconf.service To have the domain_name_servers= in the file /etc/dhcpcd.conf activated/propagate, run below one: sudo systemctl restart dhcpcd And check with below one if IP(s) on the nameserver line(s) reflects the ones in the /etc/dhcpcd.conf file: cat /etc/resolv.conf Add logging to unbound Warning It's not recommended to increase verbosity for daily use, as unbound logs a lot. But it might be helpful for debugging purposes. There are five levels of verbosity Level 0 means no verbosity, only errors Level 1 gives operational information Level 2 gives detailed operational information Level 3 gives query level information Level 4 gives algorithm level information Level 5 logs client identification for cache misses First, specify the log file and the verbosity level in the server part of /etc/unbound/unbound.conf.d/pi-hole.conf: server: # If no logfile is specified, syslog is used logfile: "/var/log/unbound/unbound.log" verbosity: 1 Second, create log dir and file, set permissions: sudo mkdir -p /var/log/unbound sudo touch /var/log/unbound/unbound.log sudo chown unbound /var/log/unbound/unbound.log Third, restart unbound: sudo service unbound restart