Jump to content

All Activity

This stream auto-updates

  1. Earlier
  2. 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.
  3. 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
  4. brent

    adguard-sync

    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 # ################
  5. 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 Allowing Established and Related Incoming Connections 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 Allowing Established Outgoing Connections 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 Allowing Internal Network to access External 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 Dropping Invalid Packets 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 Blocking an IP Address 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 Blocking Connections to a Network Interface 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. Service: SSH 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. Allowing All Incoming SSH 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. Allowing Incoming SSH from Specific IP address or subnet 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. Allowing Outgoing SSH 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 Allowing Incoming Rsync from Specific IP Address or Subnet 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. Service: Web Server 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. Allowing All Incoming HTTP 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. Allowing All Incoming HTTPS 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. Allowing All Incoming HTTP and HTTPS 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. Service: MySQL 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. Allowing MySQL from Specific IP Address or Subnet 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. Allowing MySQL to Specific Network Interface 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. Service: PostgreSQL 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. PostgreSQL from Specific IP Address or Subnet 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. Allowing PostgreSQL to Specific Network Interface 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. Service: Mail 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. Blocking 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. Allowing All Incoming SMTP 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. Allowing All Incoming IMAP 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. Allowing All Incoming IMAPS 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. Allowing All Incoming POP3 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. Allowing All Incoming POP3S 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.
  6. 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.
  7. 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. Change the number of bits in the generated key to 4096 and click Generated. Move the mouse in the open area until complete. Copy the public key to Notepad and save it in the SSH keys folder. Now save the private key to the SSH key folder. You can close PuTTYgen once the files have been saved. Now you should have two files in the folder ssh keys. Copying the Public key to the Linux server. Open Putty and login to your Linux server. 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. On the left side navigate to SSH > Auth > Credentials and click Browse to point to the Private key. 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 Let's verify the public key is working. ssh [email protected] If the key is working you won't be prompted for a password.
  8. 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.
  9. 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.
  10. Tautulli will be installed to /opt/Tautulli. Open a terminal Install Git Ubuntu/Debian: sudo apt-get install git-core Fedora: sudo yum install git Install prerequisites: Ubuntu/Debian: sudo apt-get install python python-setuptools tzdata Fedora: sudo yum install python python2-setuptools Type: cd /opt Type: sudo git clone https://github.com/Tautulli/Tautulli.git Optional: Ubuntu/Debian: sudo addgroup tautulli && sudo adduser --system --no-create-home tautulli --ingroup tautulli CentOS/Fedora: sudo adduser --system --no-create-home tautulli sudo chown tautulli:tautulli -R /opt/Tautulli Type: cd Tautulli to start Tautulli Type: python Tautulli.py Tautulli will be loaded in your browser or listening on http://localhost:8181 To run Tautulli in the background on startup: # Tautulli - Stats for Plex Media Server usage # # Service Unit file for systemd system manager # # INSTALLATION NOTES # # 1. Copy this file into your systemd service unit directory (often '/lib/systemd/system') # and name it 'tautulli.service' with the following command: # sudo cp /opt/Tautulli/init-scripts/init.systemd /lib/systemd/system/tautulli.service # # 2. Edit the new tautulli.service file with configuration settings as required. # More details in the "CONFIGURATION NOTES" section shown below. # # 3. Enable boot-time autostart with the following commands: # sudo systemctl daemon-reload # sudo systemctl enable tautulli.service # # 4. Start now with the following command: # sudo systemctl start tautulli.service # # CONFIGURATION NOTES # # - The example settings in this file assume that you will run Tautulli as user: tautulli # - The example settings in this file assume that Tautulli is installed to: /opt/Tautulli # # - To create this user and give it ownership of the Tautulli directory: # Ubuntu/Debian: sudo addgroup tautulli && sudo adduser --system --no-create-home tautulli --ingroup tautulli # CentOS/Fedora: sudo adduser --system --no-create-home tautulli # sudo chown tautulli:tautulli -R /opt/Tautulli # # - Adjust ExecStart= to point to: # 1. Your Tautulli executable # - Default: /opt/Tautulli/Tautulli.py # 2. Your config file (recommended is to put it somewhere in /etc) # - Default: --config /opt/Tautulli/config.ini # 3. Your datadir (recommended is to NOT put it in your Tautulli exec dir) # - Default: --datadir /opt/Tautulli # # - Adjust User= and Group= to the user/group you want Tautulli to run as. # # - WantedBy= specifies which target (i.e. runlevel) to start Tautulli for. # multi-user.target equates to runlevel 3 (multi-user text mode) # graphical.target equates to runlevel 5 (multi-user X11 graphical mode) [Unit] Description=Tautulli - Stats for Plex Media Server usage Wants=network-online.target After=network-online.target [Service] ExecStart=/opt/Tautulli/Tautulli.py --config /opt/Tautulli/config.ini --datadir /opt/Tautulli --quiet --daemon --nolaunch GuessMainPID=no Type=forking User=tautulli Group=tautulli [Install] WantedBy=multi-user.target
  11. Step 1 - Add Plex Repository The first step we need to do for this guide is to add the Plex repository to our CentOS 7 system. Go to the 'yum.repos.d' directory and create new repo file 'plex.repo' using the vim editor. cd /etc/yum.repos.d/ vim plex.repo Paste the following Plex repository configuration there. # Plex.repo file will allow dynamic install/update of plexmediaserver. [PlexRepo] name=PlexRepo baseurl=https://downloads.plex.tv/repo/rpm/$basearch/ enabled=1 gpgkey=https://downloads.plex.tv/plex-keys/PlexSign.key gpgcheck=1 Save and exit. Plex repository has been added to the CentOS 7 system. Step 2 - Install Plex Media Server on CentOS 7\8 Now we will install Plex media server on our CentOS server. Run the yum command below. sudo yum -y install plexmediaserver After the installation is complete, start the plex service and enable it to launch everytime at system boot using the systemctl commands below. systemctl start plexmediaserver systemctl enable plexmediaserver Plex media server has been installed - check it using the following command. systemctl status plexmediaserver And you will get the result as shown below. The Plex Media Server is now running on the CentOS 7 server. Step 2 - remove Plex Media Server on CentOS 7\8 To completely remove the Plex Media Server from the computer, first make sure the Plex Media Server is not running. Then do the following: Run the command rpm -e plexmediaserver Remove the directory /var/lib/plexmediaserver/ Run the command userdel plex Step 3 - Configure Firewalld Rules for Plex Media Server In this tutorial, we will enable Firewalld services. Make sure firewalld packages are installed on the system. Or you can install them using the yum command below. sudo yum -y install firewalld Now start the firewalld service and enable it to launch every time at system boot. systemctl start firewalld systemctl enable firewalld Next, we need to add new firewalld configuration for our plex installation. Plex media server needs some port in the 'LISTEN' state, so we will create new firewalld XML configuration. Go to the '/etc/firewalld/service' directory and create a new service firewalld configuration 'plex.xml' using vim. cd /etc/firewalld/services/ vim plexmediaserver.xml There, paste the following configuration. <?xml version="1.0" encoding="utf-8"?> <service> <short>plexmediaserver</short> <description>Ports required by plexmediaserver.</description> <port protocol="tcp" port="32400"></port> <port protocol="udp" port="1900"></port> <port protocol="tcp" port="3005"></port> <port protocol="udp" port="5353"></port> <port protocol="tcp" port="8324"></port> <port protocol="udp" port="32410"></port> <port protocol="udp" port="32412"></port> <port protocol="udp" port="32413"></port> <port protocol="udp" port="32414"></port> <port protocol="tcp" port="32469"></port> </service> Save and exit. Now add the 'plexmediaserver' service to the firewalld services list, then reload the configuration. sudo firewall-cmd --add-service=plexmediaserver --permanent sudo firewall-cmd --reload And you will get the result as below. The plexmediaserver service has been added to firewalld - check it using the firewalld command below. firewall-cmd --list-all And you should get 'plexmediaserver' on service list. Step 4 - Configure Plex Media Server Before configuring the Plex media server, make sure you have an account for Plex. If not, you can register using the URL below. https://app.plex.tv/ And then login to your account. If you're a registered user and logged in with your browser, you can open your Plex media server installation url in the following way changing the IP to your server IP. http://192.168.33.10:32400/web/ And you will be redirected to the plex login as below. Click the 'SIGN IN' button.
  12. Plex is a free feature-rich media library platform that provides a way to store all your movies, shows, and other media in one place. You can access Plex from any device, whether you’re at home or on-the-go. There are many different media tools available in the world like, Kodi, Xmbc, OSMC and Mediatomb, but the Plex Media Server is perhaps one of the most popular solutions for managing media. Plex runs on Windows, macOS, Linux, FreeBSD and many more. Plex is a client-server media player system made up from two main components, 1) The Plex Media Server, which organizes music, photos and videos content from personal media libraries and streams it to their player, 2) The Players that can be the Plex web UI, Plex Apps or Plex home theater. Plex Media Server supports Chromecast, Amazon FireTV, Android, iOS, Xbox, PlayStation, Apple TV, Roku, Android TV and various types of smart TVs. If you are looking for a way to watch your movies from anywhere, then Plex is best choice for you. In this tutorial, we will learn how to install and configure Plex Media Server on Ubuntu 16.04. Requirements A server running Ubuntu 20.04 A not-root user with sudo privileges setup on your server. A static IP address 192.168.0.227 setup on your server. Getting Started Before starting, make sure your system is fully up to date by running the following command: sudo apt-get update -y sudo apt-get upgrade -y Once your system is updated, restart your system to apply all these changes with the following command: sudo reboot After restarting, log in with sudo user and proceed to the next step. 1. Install Plex Media Server First, you will need to download the latest version of the Plex from their official website. You can download it by running the following command: wget https://downloads.plex.tv/plex-media-server/1.7.5.4035-313f93718/plexmediaserver_1.7.5.4035-313f93718_amd64.deb Once Plex is downloaded, run the following command to install Plex: sudo dpkg -i plexmediaserver_1.7.5.4035-313f93718_amd64.deb Next, start Plex Media Server and enable it to start on boot time by running the following command: sudo systemctl start plexmediaserver sudo systemctl enable plexmediaserver You can check the status of Plex Media Server at any time by running the following command: sudo systemctl status plexmediaserver You should see the following output: ? plexmediaserver.service - Plex Media Server for Linux Loaded: loaded (/lib/systemd/system/plexmediaserver.service; enabled; vendor preset: enabled) Active: active (running) since Sat 2017-08-05 11:48:52 IST; 17s ago Main PID: 3243 (sh) CGroup: /system.slice/plexmediaserver.service ??3243 /bin/sh -c LD_LIBRARY_PATH=/usr/lib/plexmediaserver "/usr/lib/plexmediaserver/Plex Media Server" ??3244 /usr/lib/plexmediaserver/Plex Media Server ??3288 Plex Plug-in [com.plexapp.system] /usr/lib/plexmediaserver/Resources/Plug-ins-313f93718/Framework.bundle/Contents/Resources/Versions/ Aug 05 11:49:04 Node1 systemd[1]: Started Plex Media Server for Linux. Aug 05 11:49:04 Node1 sh[3243]: Error in command line:the argument for option '--serverUuid' should follow immediately after the equal sign Aug 05 11:49:04 Node1 sh[3243]: Crash Uploader options (all are required): Aug 05 11:49:04 Node1 sh[3243]: --directory arg Directory to scan for crash reports Aug 05 11:49:04 Node1 sh[3243]: --serverUuid arg UUID of the server that crashed Aug 05 11:49:04 Node1 sh[3243]: --userId arg User that owns this product Aug 05 11:49:04 Node1 sh[3243]: --platform arg Platform string Aug 05 11:49:04 Node1 sh[3243]: --url arg URL to upload to Aug 05 11:49:04 Node1 sh[3243]: --help show help message Aug 05 11:49:04 Node1 sh[3243]: --version arg Version of the product Next, you will need to create a directory to store your Plex media. You can create this by running the following command: sudo mkdir -p /root/plex/movie Or if you already have shares on your server, skip this step Once you are finished, you can proceed to the next step. 2. Configure Plex Now, all the components are installed on your system, it's time to configure and access Plex. Open your web browser and type the URL http://192.168.0.227:32400/web, login and follow the setup wizard. Congratulations! your Plex Media Server is ready, you are now ready to connect to it from your Plex client application or Web browser.
  13. 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])
  14. 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
  15. If the Red Hat Insights site is reflecting a different hostname simply run the following to make the insights-client check back in # insights-client --version
  16. Installing CIFS Utilities Packages To mount a Windows share on a Linux system, first you need to install the CIFS utilities package. Installing CIFS utilities on CentOS and Fedora: sudo dnf install cifs-utils Auto Mounting sudo nano /etc/fstab Add the following line to the file: # <file system> <dir> <type> <options> <dump> <pass> //WIN_SHARE_IP/share_name /mnt/win_share cifs credentials=/etc/win-credentials,file_mode=0755,dir_mode=0755 0 0 Run the following command to mount the share: mount -a Creating Credential File For better security it is recommended to use a credentials file, which contains the share username, password and domain. /etc/win-credentials The credentials file has the following format: username = user password = password domain = domain The file must not be readable by users. To set the correct permissions and ownership run: sudo chown root: /etc/win-credentials sudo chmod 600 /etc/win-credentials Create Symlink in Linux 8. Create a shortcut to your new mounted file share: Terminal way (the link will appear in the folder the terminal points to): ln -s /folderorfile/link/will/point/to /name/of/the/link
  17. How to Import and Export Databases Export To Export a database, open up terminal, making sure that you are not logged into MySQL and type, mysqldump -u [username] -p [database name] > [database name].sql The database that you selected in the command will now be exported to your droplet. Import To import a database, first create a new blank database in the MySQL shell to serve as a destination for your data. CREATE DATABASE newdatabase; Then log out of the MySQL shell and type the following on the command line: mysql -u [username] -p newdatabase < [database name].sql With that, your chosen database has been imported into your destination database in MySQL. Create a database user login to mysql mysql -u root -p run the following command mysql> CREATE USER 'newuser'@'localhost' IDENTIFIED BY 'user_password'; Replace newuser with the new user name, and user_password with the user password. Grant Privileges to a MySQL User Account ALL PRIVILEGES – Grants all privileges to a user account. CREATE – The user account is allowed to create databases and tables. DROP - The user account is allowed to drop databases and tables. DELETE - The user account is allowed to delete rows from a specific table. INSERT - The user account is allowed to insert rows into a specific table. SELECT – The user account is allowed to read a database. UPDATE - The user account is allowed to update table rows. To grant specific privileges to a user account, use the following syntax: Grand all privileges to a user account over a specific database: mysql> GRANT ALL PRIVILEGES ON database_name.* TO 'database_user'@'localhost'; Grand all privileges to a user account on all databases: mysql> GRANT ALL PRIVILEGES ON *.* TO 'database_user'@'localhost'; Grand all privileges to a user account over a specific table from a database: mysql> GRANT ALL PRIVILEGES ON database_name.table_name TO 'database_user'@'localhost'; Grant multiple privileges to a user account over a specific database: mysql> GRANT SELECT, INSERT, DELETE ON database_name.* TO database_user@'localhost'; Display MySQL User Account Privileges To find the privilege(s) granted to a specific MySQL user account, use the SHOW GRANTS statement: mysql> SHOW GRANTS FOR 'database_user'@'localhost'; The output will look something like below: +---------------------------------------------------------------------------+ | Grants for database_user@localhost | +---------------------------------------------------------------------------+ | GRANT USAGE ON *.* TO 'database_user'@'localhost' | | GRANT ALL PRIVILEGES ON `database_name`.* TO 'database_user'@'localhost' | +---------------------------------------------------------------------------+ 2 rows in set (0.00 sec) Revoke Privileges from a MySQL User Account The syntax to revoke one or more privileges from a user account is almost identical as when granting privileges. To revoke all privileges from a user account over a specific database, run the following command: mysql> REVOKE ALL PRIVILEGES ON database_name.* FROM 'database_user'@'localhost'; Remove an Existing MySQL User Account To delete a MySQL user account use the DROP USER statement: mysql> DROP USER 'user'@'localhost'
  18. Security Enhanced Linux or SELinux is a security mechanism built into the Linux kernel used by RHEL-based distributions. SELinux adds an additional layer of security to the system by allowing administrators and users to control access to objects based on policy rules. SELinux policy rules specify how processes and users interact with each other as well as how processes and users interact with files. When there is no rule explicitly allowing access to an object, such as for a process opening a file, access is denied. SELinux has three modes of operation: Enforcing: SELinux allows access based on SELinux policy rules. Permissive: SELinux only logs actions that would have been denied if running in enforcing mode. This mode is useful for debugging and creating new policy rules. Disabled: No SELinux policy is loaded, and no messages are logged. By default, in CentOS 8, SELinux is enabled and in enforcing mode. It is highly recommended to keep SELinux in enforcing mode. However, sometimes it may interfere with the functioning of some application, and you need to set it to the permissive mode or disable it completely. In this tutorial, we will explain to disable SELinux on CentOS 8. Prerequisites Only the root user or a user with sudo privileges can change the SELinux mode. Checking the SELinux Mode Use the sestatus command to check the status and the mode in which SELinux is running: sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 31 The output above shows that SELinux is enabled and set to enforcing mode. Changing SELinux Mode to Permissive When enabled, SELinux can be either in enforcing or permissive mode. You can temporarily change the mode from targeted to permissive with the following command: sudo setenforce 0 However, this change is valid for the current runtime session only and do not persist between reboots. To permanently set the SELinux mode to permissive, follow the steps below: Open the /etc/selinux/config file and set the SELINUX mod to permissive: /etc/selinux/config # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=permissive # SELINUXTYPE= can take one of these three values: # targeted - Targeted processes are protected, # minimum - Modification of targeted policy. Only selected processes are protected. # mls - Multi Level Security protection. SELINUXTYPE=targeted Save the file and run the setenforce 0 command to change the SELinux mode for the current session: sudo shutdown -r now Disabling SELinux Instead of disabling SELinux, it is strongly recommended to change the mode to permissive. Disable SELinux only when required for the proper functioning of your application. Perform the steps below to disable SELinux on your CentOS 8 system permanently: Open the /etc/selinux/config file and change the SELINUX value to disabled: /etc/selinux/config # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=disabled # SELINUXTYPE= can take one of these three values: # targeted - Targeted processes are protected, # minimum - Modification of targeted policy. Only selected processes are protected. # mls - Multi Level Security protection. SELINUXTYPE=targeted Save the file and reboot the system: sudo shutdown -r now When the system is booted, use the sestatus command to verify that SELinux has been disabled: sestatus The output should look like this: SELinux status: disabled Conclusion SELinux is a mechanism to secure a system by implementing mandatory access control (MAC). SELinux is enabled by default on CentOS 8 systems, but it can be disabled by editing the configuration file and rebooting the system. To learn more about the powerful features of SELinux, visit the CentOS SELinux guide.
  19. Introduction The Apache HTTP server is the most widely-used web server in the world. It provides many powerful features including dynamically loadable modules, robust media support, and extensive integration with other popular software. In this guide, you will install an Apache web server with virtual hosts on your CentOS 8 server. Prerequisites You will need the following to complete this guide: A non-root user with sudo privileges configured on your server. Ensure that a basic firewall is configured. Step 1 — Installing Apache Apache is available within CentOS’s default software repositories, which means you can install it with the dnf package manager. As the non-root sudo user configured in the prerequisites, install the Apache package: sudo dnf install httpd After confirming the installation, dnf will install Apache and all required dependencies. If you also plan to configure Apache to serve content over HTTPS, you will also want to open up port 443 by enabling the https service: sudo firewall-cmd --permanent --add-service=http sudo firewall-cmd --permanent --add-service=https Next, reload the firewall to put these new rules into effect: sudo firewall-cmd --reload After the firewall reloads, you are ready to start the service and check the web server. Step 2 — Checking your Web Server Apache does not automatically start on CentOS once the installation completes, so you will need to start the Apache process manually: sudo systemctl start httpd Verify that the service is running with the following command: sudo systemctl status httpd You will receive an active status when the service is running: Output ● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disa> Active: active (running) since Thu 2020-04-23 22:25:33 UTC; 11s ago Docs: man:httpd.service(8) Main PID: 14219 (httpd) Status: "Running, listening on: port 80" Tasks: 213 (limit: 5059) Memory: 24.9M CGroup: /system.slice/httpd.service ├─14219 /usr/sbin/httpd -DFOREGROUND ├─14220 /usr/sbin/httpd -DFOREGROUND ├─14221 /usr/sbin/httpd -DFOREGROUND ├─14222 /usr/sbin/httpd -DFOREGROUND └─14223 /usr/sbin/httpd -DFOREGROUND ... As this output indicates, the service has started successfully. However, the best way to test this is to request a page from Apache. You can access the default Apache landing page to confirm that the software is running properly through your IP address. If you do not know your server’s IP address, you can get it a few different ways from the command line. Type q to return to the command prompt and then type: hostname -I This command will display all of the host’s network addresses, so you will get back a few IP addresses separated by spaces. You can try each in your web browser to determine whether they work. Alternatively, you can use curl to request your IP from icanhazip.com, which will give you your public IPv4 address as read from another location on the internet: curl -4 icanhazip.com When you have your server’s IP address, enter it into your browser’s address bar: http://your_server_ip You’ll see the default CentOS 8 Apache web page: This page indicates that Apache is working correctly. It also includes some basic information about important Apache files and directory locations. Step 3 — Managing the Apache Process Now that the service is installed and running, you can now use different systemctl commands to manage the service. To stop your web server, type: sudo systemctl stop httpd To start the web server when it is stopped, type: sudo systemctl start httpd To stop and then start the service again, type: sudo systemctl restart httpd If you are simply making configuration changes, Apache can often reload without dropping connections. To do this, use this command: sudo systemctl reload httpd By default, Apache is configured to start automatically when the server boots. If this is not what you want, disable this behavior by typing: sudo systemctl disable httpd To re-enable the service to start up at boot, type: sudo systemctl enable httpd Apache will now start automatically when the server boots again. The default configuration for Apache will allow your server to host a single website. If you plan on hosting multiple domains on your server, you will need to configure virtual hosts on your Apache web server. Step 4 — Setting Up Virtual Hosts (Recommended) When using the Apache web server, you can use virtual hosts (if you are more familiar with Nginx, these are similar to server blocks) to encapsulate configuration details and host more than one domain from a single server. In this step, you will set up a domain called example.com, but you should replace this with your own domain name. Apache on CentOS 8 has one virtual host enabled by default that is configured to serve documents from the /var/www/html directory. While this works well for a single site, it can become unwieldy if you are hosting multiple sites. Instead of modifying /var/www/html, you will create a directory structure within /var/www for the example.com site, 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 html directory for example.com as follows, using the -p flag to create any necessary parent directories: sudo mkdir -p /var/www/example.com/html Create an additional directory to store log files for the site: sudo mkdir -p /var/www/example.com/log Next, assign ownership of the html directory with the $USER environmental variable: sudo chown -R $USER:$USER /var/www/example.com/html Make sure that your web root has the default permissions set: sudo chmod -R 755 /var/www Next, create a sample index.html page using vi or your favorite editor: sudo vi /var/www/example.com/html/index.html Press i to switch to INSERT mode and add the following sample HTML to the file: /var/www/example.com/html/index.html <html> <head> <title>Welcome to Example.com!</title> </head> <body> <h1>Success! The example.com virtual host is working!</h1> </body> </html> Save and close the file by pressing ESC, typing :wq, and pressing ENTER. With your site directory and sample index file in place, you are almost ready to create the virtual host files. Virtual host files specify the configuration of your separate sites and tell the Apache web server how to respond to various domain requests. Before you create your virtual hosts, you will need to create a sites-available directory to store them in. You will also create the sites-enabled directory that tells Apache that a virtual host is ready to serve to visitors. The sites-enabled directory will hold symbolic links to virtual hosts that we want to publish. Create both directories with the following command: sudo mkdir /etc/httpd/sites-available /etc/httpd/sites-enabled Next, you will tell Apache to look for virtual hosts in the sites-enabled directory. To accomplish this, edit Apache’s main configuration file using vi or your favorite text editor and add a line declaring an optional directory for additional configuration files: sudo vi /etc/httpd/conf/httpd.conf Press capital G to navigate towards the end of the file. Then press i to switch to INSERT mode and add the following line to the very end of the file: /etc/httpd/conf/httpd.conf ... # Supplemental configuration # # Load config files in the "/etc/httpd/conf.d" directory, if any. IncludeOptional conf.d/*.conf IncludeOptional sites-enabled/*.conf Save and close the file when you are done adding that line. Now that you have your virtual host directories in place, you will create your virtual host file. Start by creating a new file in the sites-available directory: sudo vi /etc/httpd/sites-available/example.com.conf Add in the following configuration block, and change the example.com domain to your domain name: /etc/httpd/sites-available/example.com.conf <VirtualHost *:80> ServerName www.example.com ServerAlias example.com DocumentRoot /var/www/example.com/html ErrorLog /var/www/example.com/log/error.log CustomLog /var/www/example.com/log/requests.log combined </VirtualHost> Copy This will tell Apache where to find the root directly that holds the publicly accessible web documents. It also tells Apache where to store error and request logs for this particular site. Save and close the file when you are finished. Now that you have created the virtual host files, you will enable them so that Apache knows to serve them to visitors. To do this, create a symbolic link for each virtual host in the sites-enabled directory: sudo ln -s /etc/httpd/sites-available/example.com.conf /etc/httpd/sites-enabled/example.com.conf Your virtual host is now configured and ready to serve content. Before restarting the Apache service, let’s make sure that SELinux has the correct policies in place for your virtual hosts. Step 5 — Adjusting SELinux Permissions for Virtual Hosts (Recommended) SELinux is a Linux kernel security module that brings heightened security for Linux systems. CentOS 8 comes equipped with SELinux configured to work with the default Apache configuration. Since you changed the default configuration by setting up a custom log directory in the virtual hosts configuration file, you will receive an error if you attempt to start the Apache service. To resolve this, you need to update the SELinux policies to allow Apache to write to the necessary files. There are different ways to set policies based on your environment’s needs as SELinux allows you to customize your security level. This step will cover two methods of adjusting Apache policies: universally and on a specific directory. Adjusting policies on directories is more secure, and is therefore the recommended approach. Adjusting Apache Policies Universally Setting the Apache policy universally will tell SELinux to treat all Apache processes identically by using the httpd_unified Boolean. While this approach is more convenient, it will not give you the same level of control as an approach that focuses on a file or directory policy. Run the following command to set a universal Apache policy: sudo setsebool -P httpd_unified 1 The setsebool command changes SELinux Boolean values. The -P flag will update the boot-time value, making this change persist across reboots. httpd_unified is the Boolean that will tell SELinux to treat all Apache processes as the same type, so you enabled it with a value of 1. Adjusting Apache Policies on a Directory Individually setting SELinux permissions for the /var/www/example.com/log directory will give you more control over your Apache policies, but may also require more maintenance. Since this option is not universally setting policies, you will need to manually set the context type for any new log directories specified in your virtual host configurations. First, check the context type that SELinux gave the /var/www/example.com/log directory: sudo ls -dlZ /var/www/example.com/log/ This command lists and prints the SELinux context of the directory. You will receive output similar to the following: Output drwxr-xr-x. 2 root root unconfined_u:object_r:httpd_sys_content_t:s0 6 Apr 23 23:51 /var/www/example.com/log/ The current context is httpd_sys_content_t, which tells SELinux that the Apache process can only read files created in this directory. In this tutorial, you will change the context type of the /var/www/example.com/log directory to httpd_log_t. This type will allow Apache to generate and append to web application log files: sudo semanage fcontext -a -t httpd_log_t "/var/www/example.com/log(/.*)?" Next, use the restorecon command to apply these changes and have them persist across reboots: sudo restorecon -R -v /var/www/example.com/log The -R flag runs this command recursively, meaning it will update any existing files to use the new context. The -v flag will print the context changes the command made. You will receive the following output confirming the changes: Output Relabeled /var/www/example.com/log from unconfined_u:object_r:httpd_sys_content_t:s0 to unconfined_u:object_r:httpd_log_t:s0 You can list the contexts once more to see the changes: sudo ls -dlZ /var/www/example.com/log/ The output reflects the updated context type: Output drwxr-xr-x. 2 root root unconfined_u:object_r:httpd_log_t:s0 6 Apr 23 23:51 /var/www/example.com/log/ Now that the /var/www/example.com/log directory is using the httpd_log_t type, you are ready to test your virtual host configuration. Step 6 — Testing the Virtual Host (Recommended) Once the SELinux context has been updated with either method, Apache will be able to write to the /var/www/example.com/log directory. You can now successfully restart the Apache service: sudo systemctl restart httpd List the contents of the /var/www/example.com/log directory to see if Apache created the log files: ls -lZ /var/www/example.com/log You’ll receive confirmation that Apache was able to create the error.log and requests.log files specified in the virtual host configuration: Output -rw-r--r--. 1 root root system_u:object_r:httpd_log_t:s0 0 Apr 24 00:06 error.log -rw-r--r--. 1 root root system_u:object_r:httpd_log_t:s0 0 Apr 24 00:06 requests.log Now that you have your virtual host set up and SELinux permissions updated, Apache will now serve your domain name. You can test this by navigating to http://example.com, where you should see something like this: This confirms that your virtual host is successfully configured and serving content. Repeat Steps 4 and 5 to create new virtual hosts with SELinux permissions for additional domains.
  20. Step 1 — Installing OpenVPN To start, we will install OpenVPN on the server. We'll also install Easy RSA, a public key infrastructure management tool which will help us set up an internal certificate authority (CA) for use with our VPN. We'll also use Easy RSA to generate our SSL key pairs later on to secure the VPN connections. Log in to the server as the non-root sudo user, and update the package lists to make sure you have all the latest versions. sudo yum update -y The Extra Packages for Enterprise Linux (EPEL) repository is an additional repository managed by the Fedora Project containing non-standard but popular packages. OpenVPN isn't available in the default CentOS repositories but it is available in EPEL, so install EPEL: sudo yum install epel-release -y Then update your package lists once more: sudo yum update -y Next, install OpenVPN and wget, which we will use to install Easy RSA: sudo yum install -y openvpn wget Using wget, download Easy RSA. For the purposes of this tutorial, we recommend using easy-rsa-2 because there’s more available documentation for this version. You can find the download link for the latest version of easy-rsa-2 on the project’s Releases page: wget -O /tmp/easyrsa https://github.com/OpenVPN/easy-rsa-old/archive/2.3.3.tar.gz Next, extract the compressed file with tar: tar xfz /tmp/easyrsa This will create a new directory on your server called easy-rsa-old-2.3.3. Make a new subdirectory under /etc/openvpn and name it easy-rsa: sudo mkdir /etc/openvpn/easy-rsa Copy the extracted Easy RSA files over to the new directory: sudo cp -rf easy-rsa-old-2.3.3/easy-rsa/2.0/* /etc/openvpn/easy-rsa Then change the directory’s owner to your non-root sudo user: sudo chown sammy /etc/openvpn/easy-rsa/ Once these programs are installed and have been moved to the right locations on your system, the next step is to customize the server-side configuration of OpenVPN. Step 2 — Configuring OpenVPN Like many other widely-used open-source tools, there are dozens of configuration options available to you. In this section, we will provide instructions on how to set up a basic OpenVPN server configuration. OpenVPN has several example configuration files in its documentation directory. First, copy the sample server.conf file as a starting point for your own configuration file. sudo cp /usr/share/doc/openvpn-2.4.4/sample/sample-config-files/server.conf /etc/openvpn Open the new file for editing with the text editor of your choice. We’ll use nano in our example, which you can download with the yum install nano command if you don’t have it on your server already: sudo nano /etc/openvpn/server.conf There are a few lines we need to change in this file, most of which just need to be uncommented by removing the semicolon, ;, at the beginning of the line. The functions of these lines, and the other lines not mentioned in this tutorial, are explained in-depth in the comments above each one. To get started, find and uncomment the line containing push "redirect-gateway def1 bypass-dhcp". Doing this will tell your client to redirect all of its traffic through your OpenVPN server. Be aware that enabling this functionality can cause connectivity issues with other network services, like SSH: /etc/openvpn/server.conf push "redirect-gateway def1 bypass-dhcp" Because your client will not be able to use the default DNS servers provided by your ISP (as its traffic will be rerouted), you need to tell it which DNS servers it can use to connect to OpenVPN. You can pick different DNS servers, but here we'll use Google's public DNS servers which have the IPs of 8.8.8.8 and 8.8.4.4. Set this by uncommenting both push "dhcp-option DNS ..." lines and updating the IP addresses: /etc/openvpn/server.conf push "dhcp-option DNS 8.8.8.8" push "dhcp-option DNS 8.8.4.4" We want OpenVPN to run with no privileges once it has started, so we need to tell it to run with a user and group of nobody. To enable this, uncomment the user nobody and group nobody lines: /etc/openvpn/server.conf user nobody group nobody Next, uncomment the topology subnet line. This, along with the server 10.8.0.0 255.255.255.0 line below it, configures your OpenVPN installation to function as a subnetwork and tells the client machine which IP address it should use. In this case, the server will become 10.8.0.1 and the first client will become 10.8.0.2: /etc/openvpn/server.conf topology subnet It’s also recommended that you add the following line to your server configuration file. This double checks that any incoming client certificates are truly coming from a client, hardening the security parameters we will establish in later steps: /etc/openvpn/server.conf remote-cert-eku "TLS Web Client Authentication" Lastly, OpenVPN strongly recommends that users enable TLS Authentication, a cryptographic protocol that ensures secure communications over a computer network. To do this, you will need to generate a static encryption key (named in our example as myvpn.tlsauth, although you can choose any name you like). Before creating this key, comment the line in the configuration file containing tls-auth ta.key 0 by prepending it with a semicolon. Then, add tls-crypt myvpn.tlsauth to the line below it: /etc/openvpn/server.conf ;tls-auth ta.key 0 tls-crypt myvpn.tlsauth Save and exit the OpenVPN server configuration file (in nano, press CTRL - X, Y, then ENTER to do so), and then generate the static encryption key with the following command: sudo openvpn --genkey --secret /etc/openvpn/myvpn.tlsauth Now that your server is configured, you can move on to setting up the SSL keys and certificates needed to securely connect to your VPN connection. Step 3 — Generating Keys and Certificates Easy RSA uses a set of scripts that come installed with the program to generate keys and certificates. In order to avoid re-configuring every time you need to generate a certificate, you can modify Easy RSA’s configuration to define the default values it will use for the certificate fields, including your country, city, and preferred email address. We’ll begin our process of generating keys and certificates by creating a directory where Easy RSA will store any keys and certs you generate: sudo mkdir /etc/openvpn/easy-rsa/keys The default certificate variables are set in the vars file in /etc/openvpn/easy-rsa, so open that file for editing: sudo nano /etc/openvpn/easy-rsa/vars Scroll to the bottom of the file and change the values that start with export KEY_ to match your information. The ones that matter the most are: KEY_CN: Here, enter the domain or subdomain that resolves to your server. KEY_NAME: You should enter server here. If you enter something else, you would also have to update the configuration files that reference server.key and server.crt. The other variables in this file that you may want to change are: KEY_COUNTRY: For this variable, enter the two-letter abbreviation of the country of your residence. KEY_PROVINCE: This should be the name or abbreviation of the state of your residence. KEY_CITY: Here, enter the name of the city you live in. KEY_ORG: This should be the name of your organization or company. KEY_EMAIL: Enter the email address that you want to be connected to the security certificate. KEY_OU: This should be the name of the “Organizational Unit” to which you belong, typically either the name of your department or team. The rest of the variables can be safely ignored outside of specific use cases. After you’ve made your changes, the file should look like this: /etc/openvpn/easy-rsa/vars . . . # These are the default values for fields # which will be placed in the certificate. # Don't leave any of these fields blank. export KEY_COUNTRY="US" export KEY_PROVINCE="NY" export KEY_CITY="New York" export KEY_ORG="DigitalOcean" export KEY_EMAIL="[email protected]" export [email protected] export KEY_CN=openvpn.example.com export KEY_NAME="server" export KEY_OU="Community" . . . Save and close the file. To start generating the keys and certificates, move into the easy-rsa directory and source in the new variables you set in the vars file: cd /etc/openvpn/easy-rsa source ./vars Run Easy RSA’s clean-all script to remove any keys and certificates already in the folder and generate the certificate authority: ./clean-all Next, build the certificate authority with the build-ca script. You'll be prompted to enter values for the certificate fields, but if you set the variables in the vars file earlier, all of your options will already be set as the defaults. You can press ENTER to accept the defaults for each one: ./build-ca This script generates a file called ca.key. This is the private key used to sign your server and clients’ certificates. If it is lost, you can no longer trust any certificates from this certificate authority, and if anyone is able to access this file they can sign new certificates and access your VPN without your knowledge. For this reason, OpenVPN recommends storing ca.key in a location that can be offline as much as possible, and it should only be activated when creating new certificates. Next, create a key and certificate for the server using the build-key-server script: ./build-key-server server As with building the CA, you'll see the values you’ve set as the defaults so you can hit ENTER at these prompts. Additionally, you’ll be prompted to enter a challenge password and an optional company name. If you enter a challenge password, you will be asked for it when connecting to the VPN from your client. If you don’t want to set a challenge password, just leave this line blank and press ENTER. At the end, enter Y to commit the changes. The last part of creating the server keys and certificates is generating a Diffie-Hellman key exchange file. Use the build-dh script to do this: ./build-dh This may take a few minutes to complete. Once your server is finished generating the key exchange file, copy the server keys and certificates from thekeys directory into the openvpn directory: cd /etc/openvpn/easy-rsa/keys sudo cp dh2048.pem ca.crt server.crt server.key /etc/openvpn Each client will also need a certificate in order for the OpenVPN server to authenticate it. These keys and certificates will be created on the server and then you will have to copy them over to your clients, which we will do in a later step. It’s advised that you generate separate keys and certificates for each client you intend to connect to your VPN. Because we'll only set up one client here, we called it client, but you can change this to a more descriptive name if you’d like: cd /etc/openvpn/easy-rsa ./build-key client Finally, copy the versioned OpenSSL configuration file, openssl-1.0.0.cnf, to a versionless name, openssl.cnf. Failing to do so could result in an error where OpenSSL is unable to load the configuration because it cannot detect its version: cp /etc/openvpn/easy-rsa/openssl-1.0.0.cnf /etc/openvpn/easy-rsa/openssl.cnf Now that all the necessary keys and certificates have been generated for your server and client, you can move on to setting up routing between the two machines. Step 4 — Routing So far, you’ve installed OpenVPN on your server, configured it, and generated the keys and certificates needed for your client to access the VPN. However, you have not yet provided OpenVPN with any instructions on where to send incoming web traffic from clients. You can stipulate how the server should handle client traffic by establishing some firewall rules and routing configurations. Assuming you followed the prerequisites at the start of this tutorial, you should already have firewalld installed and running on your server. To allow OpenVPN through the firewall, you’ll need to know what your active firewalld zone is. Find this with the following command: sudo firewall-cmd --get-active-zones Output trusted Interfaces: tun0 Next, add the openvpn service to the list of services allowed by firewalld within your active zone, and then make that setting permanent by running the command again but with the --permanent option added: sudo firewall-cmd --zone=trusted --add-service openvpn sudo firewall-cmd --zone=trusted --add-service openvpn --permanent You can check that the service was added correctly with the following command: sudo firewall-cmd --list-services --zone=trusted Output openvpn Next, add a masquerade to the current runtime instance, and then add it again with the --permanentoption to add the masquerade to all future instances: sudo firewall-cmd --add-masquerade sudo firewall-cmd --permanent --add-masquerade You can check that the masquerade was added correctly with this command: sudo firewall-cmd --query-masquerade Output yes Next, forward routing to your OpenVPN subnet. You can do this by first creating a variable (SHARK in our example) which will represent the primary network interface used by your server, and then using that variable to permanently add the routing rule: SHARK=$(ip route get 8.8.8.8 | awk 'NR==1 {print $(NF-2)}') Be sure to implement these changes to your firewall rules by reloading firewalld: sudo firewall-cmd --reload Next, enable IP forwarding. This will route all web traffic from your client to your server’s IP address, and your client’s public IP address will effectively be hidden. Open sysctl.conf for editing: sudo nano /etc/sysctl.conf Then add the following line at the top of the file: /etc/sysctl.conf net.ipv4.ip_forward = 1 Finally, restart the network service so the IP forwarding will take effect: sudo systemctl restart network.service With the routing and firewall rules in place, we can start the OpenVPN service on the server. Step 5 — Starting OpenVPN OpenVPN is managed as a systemd service using systemctl. We will configure OpenVPN to start up at boot so you can connect to your VPN at any time as long as your server is running. To do this, enable the OpenVPN server by adding it to systemctl: sudo systemctl -f enable [email protected] Then start the OpenVPN service: sudo systemctl start [email protected] Double check that the OpenVPN service is active with the following command. You should see active (running) in the output: sudo systemctl status [email protected] Output: We’ve now completed the server-side configuration for OpenVPN. Next, you will configure your client machine and connect to the OpenVPN server. Step 6 — Configuring a Client Regardless of your client machine's operating system, it will need a locally-saved copy of the CA certificate and the client key and certificate generated in Step 3, as well as the static encryption key you generated at the end of Step 2. Locate the following files on your server. If you generated multiple client keys with unique, descriptive names, then the key and certificate names will be different. In this article we used client. /etc/openvpn/easy-rsa/keys/ca.crt /etc/openvpn/easy-rsa/keys/client.crt /etc/openvpn/easy-rsa/keys/client.key /etc/openvpn/myvpn.tlsauth Copy these files to your client machine. You can use SFTP or your preferred method. You could even just open the files in your text editor and copy and paste the contents into new files on your client machine. Regardless of which method you use, be sure to note where you save these files. Next, create a file called client.ovpn on your client machine. This is a configuration file for an OpenVPN client, telling it how to connect to the server: sudo nano client.ovpn Then add the following lines to client.ovpn. Notice that many of these lines reflect those which we uncommented or added to the server.conf file, or were already in it by default: client.ovpn client tls-client ca /path/to/ca.crt cert /path/to/client.crt key /path/to/client.key tls-crypt /path/to/myvpn.tlsauth remote-cert-eku "TLS Web Client Authentication" proto udp remote your_server_ip 1194 udp dev tun topology subnet pull user nobody group nobody When adding these lines, please note the following: You'll need to change the first line to reflect the name you gave the client in your key and certificate; in our case, this is just client You also need to update the IP address from your_server_ip to the IP address of your server; port 1194 can stay the same Make sure the paths to your key and certificate files are correct This file can now be used by any OpenVPN client to connect to your server. Below are OS-specific instructions for how to connect your client: Windows: On Windows, you will need the official OpenVPN Community Edition binaries which come with a GUI. Place your .ovpn configuration file into the proper directory, C:\Program Files\OpenVPN\config, and click Connect in the GUI. OpenVPN GUI on Windows must be executed with administrative privileges. macOS: On macOS, the open source application Tunnelblick provides an interface similar to the OpenVPN GUI on Windows, and comes with OpenVPN and the required TUN/TAP drivers. As with Windows, the only step required is to place your .ovpn configuration file into the ~/Library/Application Support/Tunnelblick/Configurations directory. Alternatively, you can double-click on your .ovpn file. Linux: On Linux, you should install OpenVPN from your distribution's official repositories. You can then invoke OpenVPN by executing: sudo openvpn --config ~/path/to/client.ovpn After you establish a successful client connection, you can verify that your traffic is being routed through the VPN by checking Google to reveal your public IP. Conclusion You should now have a fully operational virtual private network running on your OpenVPN server. You can browse the web and download content without worrying about malicious actors tracking your activity. There are several steps you could take to customize your OpenVPN installation even further, such as configuring your client to connect to the VPN automatically or configuring client-specific rules and access policies. For these and other OpenVPN customizations, you should consult the official OpenVPN documentation. If you’re interested in other ways you can protect yourself and your machines on the internet, check out our article on 7 Security Measures to Protect Your Servers.
  21. Install Samba4 in CentOS 7 1. First install Samba4 and required packages from the default CentOS repositories using the yum package manager tool as shown. # yum install samba samba-client samba-common Install Samba4 on CentOS 7 2. After installing the samba packages, enable samba services to be allowed through system firewall with these commands. # firewall-cmd --permanent --zone=public --add-service=samba # firewall-cmd --reload Open Samba on Firewalld Check Windows Machine Workgroup Settings 3. Before you proceed to configure samba, make sure the Windows machine is in the same workgroup to be configured on the CentOS server. There are two possible ways to view the Windows machine workgroup settings: Right clicking on “This PC” or “My Computer” → Properties → Advanced system settings → Computer Name. Check Windows WorkGroup Alternatively, open the cmd prompt and run the following command, then look for “workstation domain” in the output as shown below. >net config workstation Verify Windows WorkGroup Configuring Samba4 on CentOS 7 4. The main samba configuration file is /etc/samba/smb.conf, the original file comes with pre-configuration settings which explain various configuration directives to guide you. But, before configuring samba, I suggest you to take a backup of the default file like this. # cp /etc/samba/smb.conf /etc/samba/smb.conf.orig Then, proceed to configure samba for anonymous and secure file sharing services as explained below. Samba4 Anonymous File Sharing 5. First create the shared directory where the files will be stored on the server and set the appropriate permissions on the directory. # mkdir -p /srv/samba/anonymous # chmod -R 0775 /srv/samba/anonymous # chown -R nobody:nobody /srv/samba/anonymous Also, you need to change the SELinux security context for the samba shared directory as follows. # chcon -t samba_share_t /srv/samba/anonymous Create Samba Shared Directory 6. Next, open the samba configuration file for editing, where you can modify/add the sections below with the corresponding directives. # vi /etc/samba/smb.conf Samba Configuration Settings [global] workgroup = WORKGROUP netbios name = centos security = user [Anonymous] comment = Anonymous File Server Share path = /srv/samba/anonymous browsable =yes writable = yes guest ok = yes read only = no force user = nobody 7. Now verify current samba settings by running the command below. # testparm Verify Samba Current Configuration Settings Load smb config files from /etc/samba/smb.conf rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384) Processing section "[homes]" Processing section "[printers]" Processing section "[print$]" Processing section "[Anonymous]" Loaded services file OK. Server role: ROLE_STANDALONE Press enter to see a dump of your service definitions # Global parameters [global] netbios name = centos printcap name = cups security = USER idmap config * : backend = tdb cups options = raw [homes] comment = Home Directories browseable = No inherit acls = Yes read only = No valid users = %S %D%w%S [printers] comment = All Printers path = /var/tmp browseable = No printable = Yes create mask = 0600 [print$] comment = Printer Drivers path = /var/lib/samba/drivers create mask = 0664 directory mask = 0775 write list = root [Anonymous] comment = Anonymous File Server Share path = /srv/samba/anonymous force user = nobody guest ok = Yes read only = No 8. Finally, start and enable samba services to start automatically at next boot and also apply the above changes to take effect. # systemctl enable smb.service # systemctl enable nmb.service # systemctl start smb.service # systemctl start nmb.service Testing Anonymous Samba File Sharing 9. Now on the Windows machine, open “Network” from a Windows Explorer window, then click on the CentOShost, or else try to access the server using its IP address (use ifconfig command to get IP address). e.g. \\192.168.43.168. Shared Network Hosts 10. Next, open the Anonymous directory and try to add files in there to share with other users. Samba Anonymous Share Add Files to Samba Anonymous Share Setup Samba4 Secure File Sharing 11. First start by creating a samba system group, then add users to the group and set a password for each user like so. # groupadd smbgrp # usermod tecmint -aG smbgrp # smbpasswd -a tecmint 12. Then create a secure directory where the shared files will be kept and set the appropriate permissions on the directory with SELinux security context for the samba. # mkdir -p /srv/samba/secure # chmod -R 0770 /srv/samba/secure # chown -R root:smbgrp /srv/samba/secure # chcon -t samba_share_t /srv/samba/secure 13. Next open the configuration file for editing and modify/add the section below with the corresponding directives. # vi /etc/samba/smb.conf Samba Secure Configuration Settings [Secure] comment = Secure File Server Share path = /srv/samba/secure valid users = @smbgrp guest ok = no writable = yes browsable = yes 14. Again, verify the samba configuration settings by running the following command. $ testparm Verify Secure Configuration Settings Load smb config files from /etc/samba/smb.conf rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384) Processing section "[homes]" Processing section "[printers]" Processing section "[print$]" Processing section "[Anonymous]" Loaded services file OK. Server role: ROLE_STANDALONE Press enter to see a dump of your service definitions # Global parameters [global] netbios name = centos printcap name = cups security = USER idmap config * : backend = tdb cups options = raw [homes] comment = Home Directories browseable = No inherit acls = Yes read only = No valid users = %S %D%w%S [printers] comment = All Printers path = /var/tmp browseable = No printable = Yes create mask = 0600 [print$] comment = Printer Drivers path = /var/lib/samba/drivers create mask = 0664 directory mask = 0775 write list = root [Anonymous] comment = Anonymous File Server Share path = /srv/samba/anonymous force user = nobody guest ok = Yes read only = No [Secure] comment = Secure File Server Share path = /srv/samba/secure read only = No valid users = @smbgrp 15. Restart Samba services to apply the changes. # systemctl restart smb.service # systemctl restart nmb.service Testing Secure Samba File Sharing 16. Go to Windows machine, open “Network” from a Windows Explorer window, then click on the CentOS host, or else try to access the server using its IP address. e.g. \\192.168.43.168. You’ll be asked to provide your username and password to login the CentOS server. Once you have entered the credentials, click OK. Samba Secure Login 17. Once you successfully login, you will see all the samba shared directories. Now securely share some files with other permitted users on the network by dropping them in Secure directory.
  22. navigate to the following location. /etc/sysconfig/network-scripts/ in this location you will find your NIC file. modify the file with your editor of choice. BOOTPROTO=dhcp To: BOOTPROTO=static Now you'll need to add the entries to set not only the IP address, but the netmask, gateway, and DNS addresses. At the bottom of that file, add the following: IPADDR=192.168.1.200 NETMASK=255.255.255.0 GATEWAY=192.168.1.1 DNS1=1.0.0.1 DNS2=1.1.1.1 DNS3=8.8.4.4 Save the file restart networking sudo systemctl restart network
  23. The CentOS 7 official software repositories have PHP 5.4 which has reached the end of life and no longer actively maintained by the developers. To keep up with the latest features and security updates, you need a newer (probably the latest) version of PHP on your CentOS 7 system. Installing PHP 7 on CentOS 7 1. To install PHP 7, you have to install and enable EPEL and Remi repository to your CentOS 7 system with the commands below. # yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm # yum install http://rpms.remirepo.net/enterprise/remi-release-7.rpm 2. Next, you need to install yum-utils, a collection of useful programs for managing yum repositories and packages. It has tools that basically extend yum’s default features. It can be used for managing (enabling or disabling) yum repositories as well as packages without any manual configuration and so much more. # yum install yum-utils 3. One of the programs provided by yum-utils is yum-config-manager, which you can use to enable Remirepository as the default repository for installing different PHP versions as shown. # yum-config-manager --enable remi-php70 [Install PHP 7.0] If you want to install PHP 7.1 or PHP 7.2 on CentOS 7, just enable it as shown. # yum-config-manager --enable remi-php71 [Install PHP 7.1] # yum-config-manager --enable remi-php72 [Install PHP 7.2] 4. Now install PHP 7 with all necessary modules with the command below. # yum install php php-mcrypt php-cli php-gd php-curl php-mysql php-ldap php-zip php-fileinfo Afterwards, double check the installed version of PHP on your system. # php -v You now have php7.0 installed
  24. 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
  25. 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
  26. 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.
  1. Load more activity
×
×
  • Create New...