Jump to content

brent

Administrators
  • Posts

    125
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by brent

  1. Are you hosting service on a dynamic IP and receiving a new IP when bouncing your router or firewall? 

    prerequisites:

    • Cloud Flare API token
    • Portainer *Optional*
    • Docker Compose from here.

    1. In portainer go to stacks. and create a new stack.

    2. Copy the below docker-compose into the editor adding your API key.

    version: '2'
    services:
      cloudflare-ddns:
        image: oznu/cloudflare-ddns:latest
        restart: always
        environment:
          - API_KEY=xxxxxxx
          - ZONE=example.com
          - SUBDOMAIN=subdomain  #remove
          - PROXIED=yes

    3. I remove the "SUBDOMAIN" environment as I use CNAME for all my subdomains. Meaning if I update the IP of my A record then my subdomains that use CNAME records are updated.

     

    4. Before clicking on deployment let's set up a test scenario. Go to Cloud Flare and change the last octet of the IP.

    5. Back in Portainer click deploy. 

    6. Go to container logs and verify the container is running. You should see the IP change.

    7. In cloud flare verify the DNS has changed to reflect your current IP.

    8. In the environment you will see a cron job to run every 5 minutes. This can be changed to your needs.

  2. Update your Instance

    It is critically important to keep your self-hosted Bitwarden instance up to date. Updates may include fixes that are important for the security of your Bitwarden instance, including patches to any vulnerabilities. Data stored in your Bitwarden vault, including passwords, should be considered critical data and therefore protected with up-to-date software.

    Additionally, newer versions of client applications may not support older versions of your self-hosted instance.

    If you're running a standard installation, update your Bitwarden instance using the same Bash (Linux or macOS) or Powershell (Windows) script (bitwarden.sh) used to install Bitwarden. Run the following sequence of commands:

    Bash

    ./bitwarden.sh updateself
    ./bitwarden.sh update

     

     

     

     

     

  3. From portainer open stacks and add the below. Modify IP's of adguard servers.

    If adguard won't spin up you need to disable the host systemd-resolved

    sudo systemctl disable systemd-resolved.service
    sudo systemctl stop systemd-resolved

     

     

    ---
    version: "2.1"
    services:
      adguardhome-sync:
        image: quay.io/bakito/adguardhome-sync
        container_name: adguardhome-sync
        command: run
        environment:
          - ORIGIN_URL=http://192.168.1.26:85 #change as necessary
          - ORIGIN_USERNAME=dbtech #change as necessary
          - ORIGIN_PASSWORD=password #change as necessary
          - REPLICA_URL=http://192.168.1.27 #change as necessary
          - REPLICA_USERNAME=dbtech #change as necessary
          - REPLICA_PASSWORD=password #change as necessary
          - REPLICA1_URL=http://192.168.1.4 #change as necessary
          - REPLICA1_USERNAME=username #change as necessary
          - REPLICA1_PASSWORD=password #change as necessary
          - CRON=*/1 * * * * # run every 1 minute
          - RUNONSTART=true
        ports:
          - 8080:8080 #change as necessary
        restart: unless-stopped    
        
        
    ################
    #
    # Original Source: 
    # https://github.com/bakito/adguardhome-sync
    #
    ################

     

  4. Iptables is a firewall, installed by default on many Linux distributions.  This walk through is simple for setting up the basic server. In this tutorial we will go over how to set up iptables for the first time.  

    Note: When working with firewalls, do not block SSH communication; lock yourself out of your own server (port 22, by default).  

    Prerequisites:  

    Install iptables persistent to save iptables  

    sudo apt install iptables-persistent 

     

    make a directory /etc/iptables  

    sudo mkdir /etc/iptables  

    useful commands:  

    sudo iptables -L 
    sudo iptables -L -v 
    sudo iptables -S  

       

    Introducing new rules:  

    To begin using iptables, add the rules for authorized inbound traffic for the services you need. Iptables can keep track of the connection’s state. Therefore, use the command below to enable established connections to continue.  

    sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

    Allow traffic to a specific port to permit SSH connections by doing the following:  

    sudo iptables -A INPUT -p tcp --dport ssh -j ACCEPT

    Change the input policy to drop once you’ve added all the required authorized rules.  

    Note: Changing the default rule to drop will allow only specially allowed connections. Before modifying the default rule, ensure you’ve enabled at least SSH, as stated above.  

    sudo iptables -P INPUT DROP 

     

    Rules for saving and restoring  

    If you restart your server, all these iptables configurations will be lost. Save the rules to a file to avoid this.  

    sudo iptables-save > /etc/iptables/rules.v4  

     

    You may then just read the stored file to restore the saved rules.  

    # Overwrite the existing rules 
    sudo iptables-restore < /etc/iptables/rules.v4 
    # Append new rules while retaining the existing ones 
    sudo iptables-restore -n < /etc/iptables/rules.v4

     

    You may automate the restore procedure upon reboot by installing an extra iptables package that handles the loading of stored rules. Use the following command to do this.  

    sudo apt-get install iptables-persistent

    After installation, the first setup will prompt you to preserve the current IPv4 and IPv6 rules; choose Yes, and press Enter for both.  

       

    Saving Updates  

    If you ever think of updating your firewall and want the changes to be durable, you must save your iptables rules.  

    This command will help save your firewall rules:  

    sudo netfilter-persistent save

       

    Example of IPTABLES:  

    *filter  
    :INPUT ACCEPT [63:3208]  
    :FORWARD ACCEPT [0:0]  
    :OUTPUT ACCEPT [36:2160]  
    -A INPUT -i lo -j ACCEPT  
    -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT (Accepting all established connections)  
    -A INPUT -m conntrack --ctstate INVALID -j DROP (Drop statement if service or port doesn't match)  
    -A INPUT -s 83.97.73.245/32 -j DROP (Example of blocking bad IP)  
    -A INPUT -s 83.97.73.245/32 -j REJECT --reject-with icmp-port-unreachable (Rejecting a bad IP)  
    -A INPUT -s 192.168.1.0/24 -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW,> (Allow SSH from subnet)  
    -A INPUT -p udp -m udp --dport 137 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT (Allow port)  
    -A INPUT -p udp -m udp --dport 138 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT 
    -A INPUT -p tcp -m tcp --dport 139 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT  
    -A OUTPUT -o lo -j ACCEPT  
     
    -A OUTPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT  
     
    COMMIT  

     

    To accept all traffic on your loopback interface, run these commands:  

    sudo iptables -A INPUT -i lo -j ACCEPT 
    sudo iptables -A OUTPUT -o lo -j ACCEPT

    image.gif 

    As network traffic generally needs to be two-way – incoming and outgoing – to work properly, it is typical to create a firewall rule that allows established and related incoming traffic, so that the server will allow return traffic for outgoing connections initiated by the server itself. This command will allow that:  

    sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

       

    You may want to allow outgoing traffic of all established connections, which are typically the response to legitimate incoming connections. This command will allow that:  

    sudo iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT

     

    Assuming eth0 is your external network, and eth1 is your internal network, this will allow your internal to access the external:  

    sudo iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

     

    Some network traffic packets get marked as invalid. Sometimes it can be useful to log this type of packet but often it is fine to drop them. Do so with this command:  

    sudo iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

    image.gif 

     

    To block network connections that originate from a specific IP address, 203.0.113.51 for example, run this command:  

    sudo iptables -A INPUT -s 203.0.113.51 -j DROP

    In this example, -s 203.0.113.51 specifies a source IP address of “203.0.113.51”. The source IP address can be specified in any firewall rule, including an allow rule.  

    If you want to reject the connection instead, which will respond to the connection request with a “connection refused” error, replace “DROP” with “REJECT” like this:  

    sudo iptables -A INPUT -s 203.0.113.51 -j REJECT

       

    To block connections from a specific IP address, e.g. 203.0.113.51, to a specific network interface, e.g. eth0, use this command:  

    iptables -A INPUT -i eth0 -s 203.0.113.51 -j DROP

    This is the same as the previous example, with the addition of -i eth0. The network interface can be specified in any firewall rule, and is a great way to limit the rule to a particular network.  

    If you’re using a server without a local console, you will probably want to allow incoming SSH connections (port 22) so you can connect to and manage your server. This section covers how to configure your firewall with various SSH-related rules.  

    To allow all incoming SSH connections run these commands:  

    sudo iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT 
    sudo iptables -A OUTPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPT

    The second command, which allows the outgoing traffic of established SSH connections, is only necessary if the OUTPUT policy is not set to ACCEPT.  

     

    To allow incoming SSH connections from a specific IP address or subnet, specify the source. For example, if you want to allow the entire 203.0.113.0/24 subnet, run these commands:  

    sudo iptables -A INPUT -p tcp -s 203.0.113.0/24 --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT 
    sudo iptables -A OUTPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPT

    The second command, which allows the outgoing traffic of established SSH connections, is only necessary if the OUTPUT policy is not set to ACCEPT.  

    Here's a sample of setting up a rule which only allows SSH from a single IP:

    Add a new "allow SSH from 1.2.3.4" rule: 

    iptables -A INPUT -p tcp -s 1.2.3.4 --dport 22 -j ACCEPT

    Block SSH from all other IPs:

    iptables -A INPUT -p tcp -s 0.0.0.0/0 --dport 22 -j DROP

    Now your INPUT chain will look like:

    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination         
    ACCEPT     tcp  --  1.2.3.4              0.0.0.0/0            tcp dpt:22
    DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:22

    Later, if you need to whitelist a second IP you can use the -I parameter to place it before the blacklist rule.

    iptables -I INPUT 2 -p tcp -s 4.3.2.1 --dport 22 -j ACCEPT

     

    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination         
    ACCEPT     tcp  --  1.2.3.4              0.0.0.0/0            tcp dpt:22
    ACCEPT     tcp  --  4.3.2.1              0.0.0.0/0            tcp dpt:22
    DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:22

    Notice that using -I INPUT 2 added the new rule as rule number 2 and bumped the DROP rule to number 3.

     

    If your firewall OUTPUT policy is not set to ACCEPT, and you want to allow outgoing SSH connections—your server initiating an SSH connection to another server—you can run these commands:  

    sudo iptables -A OUTPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT 
    sudo iptables -A INPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPT  

     

     

     

    Rsync, which runs on port 873, can be used to transfer files from one computer to another.  

    To allow incoming rsync connections from a specific IP address or subnet, specify the source IP address and the destination port. For example, if you want to allow the entire 203.0.113.0/24 subnet to be able to rsync to your server, run these commands:  

    sudo iptables -A INPUT -p tcp -s 203.0.113.0/24 --dport 873 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT 
    sudo iptables -A OUTPUT -p tcp --sport 873 -m conntrack --ctstate ESTABLISHED -j ACCEPT

    The second command, which allows the outgoing traffic of established rsync connections, is only necessary if the OUTPUT policy is not set to ACCEPT.  

     

     

    Web servers, such as Apache and Nginx, typically listen for requests on port 80 and 443 for HTTP and HTTPS connections, respectively. If your default policy for incoming traffic is set to drop or deny, you will want to create rules that will allow your server to respond to those requests.  

    To allow all incoming HTTP (port 80) connections run these commands:  

    sudo iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT 
    sudo iptables -A OUTPUT -p tcp --sport 80 -m conntrack --ctstate ESTABLISHED -j ACCEPT

    The second command, which allows the outgoing traffic of established HTTP connections, is only necessary if the OUTPUT policy is not set to ACCEPT.  

     

    To allow all incoming HTTPS (port 443) connections run these commands:  

    sudo iptables -A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT 
    sudo iptables -A OUTPUT -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

    The second command, which allows the outgoing traffic of established HTTP connections, is only necessary if the OUTPUT policy is not set to ACCEPT.  

     

    If you want to allow both HTTP and HTTPS traffic, you can use the multiport module to create a rule that allows both ports. To allow all incoming HTTP and HTTPS (port 443) connections run these commands:  

     

    sudo iptables -A INPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT 
    sudo iptables -A OUTPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

    The second command, which allows the outgoing traffic of established HTTP and HTTPS connections, is only necessary if the OUTPUT policy is not set to ACCEPT.  

     

    MySQL listens for client connections on port 3306. If your MySQL database server is being used by a client on a remote server, you need to be sure to allow that traffic.  

    To allow incoming MySQL connections from a specific IP address or subnet, specify the source. For example, if you want to allow the entire 203.0.113.0/24 subnet, run these commands:  

    sudo iptables -A INPUT -p tcp -s 203.0.113.0/24 --dport 3306 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT 
    sudo iptables -A OUTPUT -p tcp --sport 3306 -m conntrack --ctstate ESTABLISHED -j ACCEPT 

    The second command, which allows the outgoing traffic of established MySQL connections, is only necessary if the OUTPUT policy is not set to ACCEPT.  

     

    To allow MySQL connections to a specific network interface—say you have a private network interface eth1, for example—use these commands:  

    sudo iptables -A INPUT -i eth1 -p tcp --dport 3306 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT 
    sudo iptables -A OUTPUT -o eth1 -p tcp --sport 3306 -m conntrack --ctstate ESTABLISHED -j ACCEPT 

    The second command, which allows the outgoing traffic of established MySQL connections, is only necessary if the OUTPUT policy is not set to ACCEPT.  

     

    PostgreSQL listens for client connections on port 5432. If your PostgreSQL database server is being used by a client on a remote server, you need to be sure to allow that traffic.  

    To allow incoming PostgreSQL connections from a specific IP address or subnet, specify the source. For example, if you want to allow the entire 203.0.113.0/24 subnet, run these commands:  

    sudo iptables -A INPUT -p tcp -s 203.0.113.0/24 --dport 5432 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT 
    sudo iptables -A OUTPUT -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPT

    The second command, which allows the outgoing traffic of established PostgreSQL connections, is only necessary if the OUTPUT policy is not set to ACCEPT.  

     

    To allow PostgreSQL connections to a specific network interface—say you have a private network interface eth1, for example—use these commands:  

    sudo iptables -A INPUT -i eth1 -p tcp --dport 5432 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT 
    sudo iptables -A OUTPUT -o eth1 -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPT

    The second command, which allows the outgoing traffic of established PostgreSQL connections, is only necessary if the OUTPUT policy is not set to ACCEPT.  

     

    Mail servers, such as Sendmail and Postfix, listen on a variety of ports depending on the protocols being used for mail delivery. If you are running a mail server, determine which protocols you are using and allow the appropriate types of traffic. We will also show you how to create a rule to block outgoing SMTP mail.  

    If your server shouldn’t be sending outgoing mail, you may want to block that kind of traffic. To block outgoing SMTP mail, which uses port 25, run this command:  

    sudo iptables -A OUTPUT -p tcp --dport 25 -j REJECT 

    This configures iptables to reject all outgoing traffic on port 25. If you need to reject a different service by its port number, instead of port 25, substitute that port number for the 25 above.  

    To allow your server to respond to SMTP connections on port 25, run these commands:  

    sudo iptables -A INPUT -p tcp --dport 25 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT 
    sudo iptables -A OUTPUT -p tcp --sport 25 -m conntrack --ctstate ESTABLISHED -j ACCEPT

    The second command, which allows the outgoing traffic of established SMTP connections, is only necessary if the OUTPUT policy is not set to ACCEPT.  

     

    To allow your server to respond to IMAP connections, port 143, run these commands:  

    sudo iptables -A INPUT -p tcp --dport 143 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT 
    sudo iptables -A OUTPUT -p tcp --sport 143 -m conntrack --ctstate ESTABLISHED -j ACCEPT

    The second command, which allows the outgoing traffic of established IMAP connections, is only necessary if the OUTPUT policy is not set to ACCEPT.  

     

    To allow your server to respond to IMAPS connections, port 993, run these commands:  

    sudo iptables -A INPUT -p tcp --dport 993 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT 
    sudo iptables -A OUTPUT -p tcp --sport 993 -m conntrack --ctstate ESTABLISHED -j ACCEPT 

    The second command, which allows the outgoing traffic of established IMAPS connections, is only necessary if the OUTPUT policy is not set to ACCEPT.  

     

     

    To allow your server to respond to POP3 connections, port 110, run these commands:  

    sudo iptables -A INPUT -p tcp --dport 110 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT 
    sudo iptables -A OUTPUT -p tcp --sport 110 -m conntrack --ctstate ESTABLISHED -j ACCEPT

    The second command, which allows the outgoing traffic of established POP3 connections, is only necessary if the OUTPUT policy is not set to ACCEPT.  

     

    To allow your server to respond to POP3S connections, port 995, run these commands:  

    sudo iptables -A INPUT -p tcp --dport 995 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT 
    sudo iptables -A OUTPUT -p tcp --sport 995 -m conntrack --ctstate ESTABLISHED -j ACCEPT

    The second command, which allows the outgoing traffic of established POP3S connections, is only necessary if the OUTPUT policy is not set to ACCEPT.  

    image.gif

    image.gif

    image.gif

    image.gif

    image.gif

    image.gif

    image.gif

    image.gif

    image.gif

    image.gif

    image.gif

    image.gif

    image.gif

    image.gif

    image.gif

    image.gif

    image.gif

    image.gif

    image.gif

    image.gif

    image.gif

    image.gif

    image.gif

  5. Prerequisites

    Login to your Gitlab system with a sudo privileged account.

    Also make sure to create an A Record points your domain/subdomain to the public IP address of your Gitab server. It is recommended to complete the let’s encrypt validation for issuing a new certification. For example, You need to configure your Gitlab server to access with https://gitlab.domain.com. So make A record in DNS for gitlab.domain.com pointing to server ip address.

     

    Configure Let’s Encrypt SSL with Gitlab

    Gitlab keeps the configuration files under /etc/gitlab directory. You can edit the main configuration file /etc/gitlab/gitlab.rb in a text editor of your choice.

    sudo vim /etc/gitlab/gitlab.rb 

     

    Make the following changes:

    First change the external_url setting with domain start with https.

    external_url "https://gitlab.tecadmin.net"

    Add or update the following entries to the configuration file. Set letsencrypt[‘enable’] to true, this will request a SSL certificate and configure to the Gitlab instance. You can also provide an optional contact email used by lets encrypt authority to send alerts for the ssl certificates.

    # Enable the Let's encrypt SSL
    letsencrypt['enable'] = true
     
    # This is optional to get SSL related alerts
    letsencrypt['contact_emails'] = ['[email protected]']
     

    Also configure Gitlab to renew SSL certificate automatically on a regular interval.

    # Enable the auto renew feature
    letsencrypt['auto_renew'] = true
     
    # This example renews every 7th day at 12:30
    letsencrypt['auto_renew_hour'] = "12"
    letsencrypt['auto_renew_minute'] = "30"
    letsencrypt['auto_renew_day_of_month'] = "*/7"

    Save the configuration file and exit from editor.

    Next, run the reconfigure command to apply changes to Gitlab server.

    sudo gitlab-ctl reconfigure

    This will take some time to complete the installation. At the end, you will see a message “gitlab Reconfigured!” on your screen.

     

    Verify SSL

    Access the Gitlab web interface in a web browser. This will automatically redirects you to secure URL.

    That’s it. You have successfully configured let’s encrypt SSL on Gitlab.

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

  6. Do you want to access your fleet of Linux servers without a password?  

    First and foremost using password authentication via SSH is a bad practice even more so if your Linux server is internet-facing.

    Using a public key to access your Linux servers is best practice and prevents brute force attacks.

    Permissions:

    from your Linux workstation, if you are getting a permission error trying to ssh to a server check the following permissions.

    ~/.ssh needs to be owned by the user account.

    Make sure authorized_keys has the correct permissions.

    ls -l .ssh/authorized_keys

    make sure it has a permission of 600.

    sudo chmod 600 ~/.ssh/authorized_keys

    make sure the ~/.ssh directory is owned by the user.

    sudo chown brent:brent ~/.ssh

    ~/.ssh/id_rsa needs to have a permission of 600.

    sudo chmod 600 ~/.ssh/id_rsa

    The id_rsa.pub public key needs to have a permission of 644.

    sudo chmod 644 ~/.ssh/id_rsa.pub

    Prerequisites:

    Windows workstation

    putty for Windows (Download putty for Windows. You can find the latest Windows installer here.

    Linux workstation

    Linux server

     

    Generating SSH keys in Windows

    Create a folder on your local computer called SSH keys. This folder can be anywhere desktop, documents, etc..

    Open PuTTygen from your start menu. 

    image.png

     

     

    Change the number of bits in the generated key to 4096 and click Generated.

    image.png

     

    Move the mouse in the open area until complete.

    image.png

     

    Copy the public key to Notepad and save it in the SSH keys folder.

    image.png

     

    Now save the private key to the SSH key folder.

    image.png

     

    You can close PuTTYgen once the files have been saved.

    Now you should have two files in the folder ssh keys.

    image.png

     

    Copying the Public key to the Linux server.

    Open Putty and login to your Linux server.

    image.png

     

    We need to check to see if a ssh folder already exists

    cd ~/.ssh

     

    if you don't have one

    sudo mkdir ~/.ssh

     

    Create a file called authorized_keys

    sudo mkdir ~/.ssh/authorized_keys

     

    Open your public key in Notepad and copy the key.

     

    Using your favorite text editor paste the key into the authorized_keys file and save. 

    If you already have an authorized_keys file, add the key on another line.

    sudo nano ~/.ssh/authorized_keys

    Log out of your server.

     

     

    Open PuTTy up to make a couple of changes.

    make sure to add user@ in front of your hostname or IP.

    image.png

     

    On the left side navigate to SSH > Auth > Credentials and click Browse to point to the Private key.

    image.png

     

    Once the Key has been added Click on Session and save the session. You will need to repeat this for every server.

     

    Create SSH keys on a Linux workstation.

     

    Let's make sure we don't have an SSH key pair.

    ls -l ~/.ssh

    If the directory exists you may want to back it up as the following command will overwrite the folder.

     

    ssh-keygen -b 4096

    Save the path in the default location.

    Enter Passphrase. This isn't required but is suggested as another layer of protection. If you choose to use a passphrase know that you will have to use the passphrase every time you log in.

     

    Let's verify that the keys have been created.

    ls -l ~/.ssh

    You should see two files id_rsa, the private key, and id_rsa.pub, the public key.

     

    Now let's copy the public key over to the server.

    ssh-copy-id [email protected]

    Type the server user password.

    Like below once you log in you should see the Number of key(s) added:1 

    image.png

     

    Let's verify the public key is working.

    ssh [email protected]

     

    If the key is working you won't be prompted for a password.

    image.png

    image.png

    image.png

  7. Install Qemu guest agent for Debian/Ubuntu

    In this article, we will help you to install the Qemu guest agent on your vm server. This agent is a helper daemon that exchanges information between the quest and the host and executes commands in the guest for snapshot or backup. The guest agent is used for mainly two things one for properly shut down the guest and the second is to freeze the guest file system when making a backup.

    Step 1: Log in using SSH

    You must be logged in via SSH with the root account or an account with sudo privileges.  

    Step 2: Install qemu guest agent

    apt update && apt -y install qemu-guest-agent

    Step 3: Enable and Start Qemu Agent

    systemctl enable qemu-guest-agent
    systemctl start qemu-guest-agent

    Step 4: Verify

    Verify that the Qemu quest agent is running

    systemctl status qemu-guest-agent

    Conclusion

    If you are having a problem with the service starting power off the VM completely then start the VM. A restart of the VM won't work in some cases. 

    Congratulations,  you have installed the Qemu guest agent on your Debian/Ubuntu based system.

  8. Setting a static IP for your headless server is a must. Here are the simple steps to accomplishing this.

    navigate to the interfaces file   /etc/netplan

    sudo nano /etc/netplan

    Here is an example of what mine looks like.

    # This is the network config written by 'subiquity'
    network:
      ethernets:
        ens18:
          addresses: [192.168.1.204/24]
          routes:
            - to: default
              via: 192.168.1.99
          nameservers:
            addresses: [8.8.8.8, 8.8.4.4]
      version: 2
    
    pre-up iptables-restore < /etc/iptables.rules
    post-down iptables-save > /etc/iptables.rules
    

     

    Save and close The last two lines pre-up and post-down is for iptables. remove those lines if you are not using the firewall.

    To apply the changes:

    sudo netplan apply

     

    If you want to verify that you are using the correct DNS:

    Use this command after you add/change your dns to restart systemd-resolved service.

    sudo systemctl restart systemd-resolved

     

    Use this command to verify the DNS routing.

    sudo resolvectl status

     

  9. On your system, if you have installed multiple versions of PHP (eg PHP 7.1 and PHP 8.4). PHP 8.4 is running as default PHP for Apache and CLI. For some web applications may have a requirement, you need to use PHP 7.1. Then you don’t need to remove PHP 8.4. You can simply switch your PHP version to default used for Apache and command line.

    For example, your server has PHP 7.1 and PHP 8.4 both version’s installed. Now following example will help you to switch between both versions.

     

     

    From PHP 8.4 => PHP 7.1

    Default PHP 5.6 is set on your system and you need to switch to PHP 7.1. Run the following commands to switch for Apache and command line.

    Apache:-

    $ sudo a2dismod php8.4
    $ sudo a2enmod php7.1
    $ sudo service apache2 restart

    Command Line:-

    $ sudo update-alternatives --set php /usr/bin/php7.1
    $ sudo update-alternatives --set phar /usr/bin/phar7.1
    $ sudo update-alternatives --set phar.phar /usr/bin/phar.phar7.1

    From PHP 7.1 => PHP 8.4

    Default PHP 7.1 is set on your system and you need to switch to PHP 5.6. Now run the following commands to switch for Apache and command line.

    Apache:-

    $ sudo a2dismod php7.1
    $ sudo a2enmod php8.4
    $ sudo service apache2 restart

    Command Line:-

    $ sudo update-alternatives --set php /usr/bin/php7.1
    $ sudo update-alternatives --set phar /usr/bin/phar7.1
    $ sudo update-alternatives --set phar.phar /usr/bin/phar.phar7.1
  10. Start up the VM and SSH to it. Of course we need root access.

    lsblk

     

    growpart /dev/sda 3

     

    pvresize /dev/sda3

     

    And increase the capacity of the lvm

    lvextend --extents +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv -r

     

    Verify with

    lsblk

     

    and

    df -h

     

    and you are done.

  11. 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:

    • 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.

    image.png

    Save the resulting “Installation Id” and “Installation Key”. These values will be required during Bitwarden installation.

    image.png

     

    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

    image.png

    Let’s enable the execution of the file “bitwarden.sh” using the command:

    chmod +x bitwarden.sh

    image.png

     

    Now let’s start the Bitwarden installation using the command:

    sudo ./bitwarden.sh install

    image.png

     

    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.

    image.png

     

    This tutorial walks you through obtaining a free cryptographic certificate through the Let’s Encrypt CA.

    Press the “y” button, then “Enter”.

    image.png

     

    We indicate the email address to which Let’s Encrypt will send notifications about the expiration of the certificate and press the “Enter” button.

    image.png

     

    Specify the database name for the Bitwarden instance and press the “Enter” button.

    image.png

     

    Specify the “Installation Id” obtained earlier and press the “Enter” button.

    image.png

     

    We indicate the “Installation Key” obtained earlier and press the “Enter” button.

    image.png

     

    Bitwarden installed successfully.

    Now let’s start Bitwarden using the command:

    sudo ./bitwarden.sh start

    image.png

     

    Bitwarden launched successfully.

    image.png

     

    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.

    image.png

     

    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

    [email protected]
    globalSettings__mail__smtp__host=smtpgmail.com
    globalSettings__mail__smtp__port=587
    globalSettings__mail__smtp__ssl=false
    [email protected]
    globalSettings__mail__smtp__password=gmail password (This is the gmail app password you created) 

    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

     

     

     

    image.png

  12. 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.

  13. 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.

  14. 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.

     

     

     

     

     

     

    proxmox - add storage.PNG

  15. 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.

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

  16. 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

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

  17. 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

                  Nginx default page

    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:

                                    Nginx server block

    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:

    PHPInfo Ubuntu 22.04

    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

     

     

     

     

     

     

     

     

     

     

     

     

     

     

  18. 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.

     

     

     

  19. 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.

  20. 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

     

  21. 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

     

     

     

     

     

     

     

     

     

  22. 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

  23. 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:

    1. Manually edit  proxmoxlib.js to undo the changes you made
    2. Restore the backup file you created from the proxmox-widget-toolkit directory:
      mv proxmoxlib.js.bak proxmoxlib.js

       

    3. Reinstall the proxmox-widget-toolkit package from the repository:
      apt-get install --reinstall proxmox-widget-toolkit

       

     

     

     

     

     

     

     

     

     

     

     

×
×
  • Create New...