How to Install Docker on Debian 10

Docker is an OS-level virtualization solution built around Linux kernel features like namespaces and cgroups to provide isolation for software packages called containers. This article will walk you through the process of installing and starting Docker on your Debian 10 server.

Prerequisites:

  • You need access to a Linux server, with sudo or root privileges.

Installation:

Before installing the Docker package, we will ensure the package cache is up to date.

$ sudo apt-get update

We will then install some needed dependencies.

$ sudo apt-get install -y apt-transport-https ca-certificates curl gnupg-agent software-properties-common

Next up, we need to import the gpg public key for the Docker CE repository

$ curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add -

Now that the gpg public key has been added, we can add the Docker CE repository.

$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable"

Update the package cache to recognize the new repository.

$ sudo apt-get update

Install the Docker-CE package.

$ sudo apt-get install -y docker-ce docker-ce-cli containerd.io

Configuration:

First, we must configure a user if we want to run docker without root privileges.  I have created a user called test_user.  The following command will add the user “test_user” to the docker group.

$ sudo usermod -a -G docker test_user

In order for the changes to be recognized, you must log out and back into your existing shell session or use the following command.

$ su test_user

Verification:

We can use systemctl to ensure the docker service is started and set to enabled at boot.

$s udo systemctl status docker.service

Check which docker version is installed.

$ docker --version

Run a test container. If this completes successfully, then you have successfully configured the docker service.

$ docker run hello-world

Conclusion

In this article, you learned how to install, configure, and verify the docker service on Debian 10.  Check out the official docker documentation for more information.

How to Install Docker on Centos 7

Docker is an OS-level virtualization solution built around Linux kernel features like namespaces and cgroups to provide isolation for software packages called containers. In this article, we’ll be walking through the installation of Docker on CentOS 7.

Prerequisites:

  •     You need access to a Linux server, with sudo or root privileges.

Installation:

We will be using yum-config-manager to setup Docker’s repository. The yum-config-manager command is in the yum-utils package. We will start off by installing yum-utils.

$ sudo yum install -y yum-utils

We can now add the Docker repository using yum-config-manager.

$ sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

Install the Docker-CE package.

$ sudo yum install docker-ce docker-ce-cli containerd.io

Configuration:

First, we must configure a user if we want to run docker without root privileges.  I have created a user called test_user.  The following command will add the user “test_user” to the docker group.

$ sudo usermod -a -G docker test_user

In order for the changes to be recognized, you must log out and back into your existing shell session or use the following command.

$ su test_user

Verification:

We can use systemctl to ensure the docker service is started and set to enabled at boot.

$ sudo systemctl status docker.service

It is neither started or enabled at boot.

Start Docker.

$ sudo systemctl start docker

Enable Docker at boot.

$ sudo systemctl enable

Check which docker version is installed.

$ docker --version

Run a test container. If this completes successfully, then you have successfully configured the docker service.

$ docker run hello-world

Conclusion

In this article, you learned how to install, configure, and verify the docker service on Centos 7.  Check out the official Docker documentation for more information.

Managing your server with Cockpit on CentOS 7

Cockpit is a web-interface for server administration.  It makes it easy to configure your system, open a terminal, view logs, or manage users–right in your browser.

Prerequisites

  • Cloud Server Running CentOS 7
  • User with sudo permissions
  • An SSL certificate (optional but recommended)

Install cockpit and Log in

To get started, we’ll first need to install the Cockpit package on our Linux system:

sudo yum install cockpit

Then we’ll need to enable the cockpit service:

sudo systemctl enable --now cockpit.socket

If you have a firewall running on your server (and you should!), you’ll need to open up a port:

sudo firewall-cmd --permanent --zone=public --add-service=cockpit && sudo firewall-cmd --reload

After Cockpit is enabled, you can access the web interface by navigating to the following in your web browser, replacing with the server’s public IP address:

https://:9090

Depending on your browser settings, you may be greeted with a warning about the SSL certificate being invalid, which is common for self-signed certificates like the default one installed with Cockpit.  We’ll replace this with a Let’s Encrypt certificate later, but for now go ahead and accept the warning.

After you’ve accepted the security warning, you’ll be able to login to Cockpit using a system user.  Check the box for “Reuse my password for privileged tasks” in order for your user to use sudo to perform actions that require elevated permissions.

Now that we’re logged in, we can see the Cockpit dashboard that has some basic information about our system and some system load stats from the last few minutes.

View system logs

  • Cockpit makes a great log viewer, showing real time system logs that can be filtered by severity and date.

Create Users

To create a new user with Cockpit, click on “Accounts” on the left panel, which will bring up a list of user accounts. Next, click “Create Account” and fill in the user information.

After a user has been created, clicking on their account will allow you to edit user information and allow you to give them roles such as “Server Administrator” (sudo) or “Container Administrator.”   Additionally, you can upload ssh keys or lock user accounts.

Update software

To update software packages using Cockpit, first select “Software Updates” from the left-hand menu. You can manually check for updates by clicking “Check for Updates”.

If you’re ready to install packages, select “Install Security Updates” to install only the most critical updates, or “Install All Updates” to update all packages on the system.

Terminal access

Selecting “Terminal” will give you the option to use an in-browser terminal as an alternative to logging into the server using ssh.

Install a custom SSL certificate (optional but recommended)

This is a recommended step to add an additional security layer by replacing the default SSL certificate with a certificate from a trusted source accepted by all major browsers:

  • Setup a DNS record pointing the IP address of your server.
  • Acquire an SSL certificate from a Trusted Provider, we recommend Let’s Encrypt.
  • Login to your server as a sudo user.
  • Copy your signed ssl certificate and key into the appropriate folder:
    sudo cp certificate.cert /etc/cockpit/ws-certs.d/
    sudo cp certificate.key /etc/cockpit/ws-certs.d/
  • To verify which certificate Cockpit will load, use the remotectl command:
    sudo remotectl certificate
    certificate: /etc/cockpit/ws-certs.d/certificate.cert

Now you can do basic server administration right in your browser using Cockpit.  Additional plugins allow for you to administer containers, manage virtual machines, and collect system metrics which we will explore in future articles.

Managing your server with Cockpit on CentOS 8

Cockpit is a web-interface for server administration.  It makes it easy to configure your system, open a terminal, view logs, or manage users–right in your browser.

Prerequisites

  • Cloud Server running CentOS 8
  • User with sudo permissions
  • An SSL certificate (optional but recommended)

Install cockpit and Log in

Cockpit is already installed on CentOS 8, it just needs to be enabled:

sudo systemctl enable --now cockpit.socket

After Cockpit is enabled, you can access the web interface by navigating to the following in your web browser, replacing with the server’s public IP address:

https://:9090

Depending on your browser settings, you may be greeted with a warning about the SSL certificate being invalid, which is common for self-signed certificates like the default one installed with Cockpit.  We’ll replace this with a Let’s Encrypt certificate later, but for now go ahead and accept the warning.

After you’ve accepted the security warning, you’ll be able to login to Cockpit using a system user.  Check the box for “Reuse my password for privileged tasks” in order for your user to use sudo to perform actions that require elevated permissions.

Now that we’re logged in, we can see the Cockpit dashboard that has some basic information about our system and some system load stats from the last few minutes.

View system logs

  • Cockpit makes a great log viewer, showing real time system logs that can be filtered by severity and date.

Create Users

To create a new user with Cockpit, click on “Accounts” on the left panel, which will bring up a list of user accounts. Next, click “Create Account” and fill in the user information.

After a user has been created, clicking on their account will allow you to edit user information and allow you to give them roles such as “Server Administrator” (sudo) or “Container Administrator.”   Additionally, you can upload ssh keys or lock user accounts.

Update software

To update software packages using Cockpit, first select “Software Updates” from the left-hand menu. You can manually check for updates by clicking “Check for Updates”.

If you’re ready to install packages, select “Install Security Updates” to install only the most critical updates, or “Install All Updates” to update all packages on the system.

Terminal access

Selecting “Terminal” will give you the option to use an in-browser terminal as an alternative to logging into the server using ssh.

Install a custom SSL certificate (optional but recommended)

This is a recommended step to add an additional security layer by replacing the default SSL certificate with a certificate from a trusted source accepted by all major browsers:

  • Setup a DNS record pointing the IP address of your server.
  • Acquire an SSL certificate from a Trusted Provider, we recommend Let’s Encrypt.
  • Login to your server as a sudo user.
  • Copy your signed ssl certificate and key into the appropriate folder:
    sudo cp certificate.cert /etc/cockpit/ws-certs.d/
    sudo cp certificate.key /etc/cockpit/ws-certs.d/
  • To verify which certificate Cockpit will load, use the remotectl command:
    sudo remotectl certificate
    certificate: /etc/cockpit/ws-certs.d/certificate.cert

Now you can do basic server administration right in your browser using Cockpit.  Additional plugins allow for you to administer containers, manage virtual machines, and collect system metrics which we will explore in future articles.

Apache or NGINX, which web server should I choose?

In the earlier days of Linux web server hosting, the only popular option was Apache.  These days however, the market share is pretty even divided between Apache, NGINX, and then other alternatives, at least on Linux and Unix based systems.  Both packages allow relatively easy setup of a web service to allow serving HTTP and HTTPS content.  Both are also completely viable options for most situations, though one or the other may be a better choice depending on circumstances.  This article aims to highlight the similarities and differences between these two options in order to allow you to make an informed choice on the best option for your needs.

A Case for Apache

Apache is the A in the popular LAMP stack (Linux, Apache, MySQL, PHP) that is still one of the most popular frameworks for serving a website in use today.  This is partially due to Apache itself, which is an extremely flexible web server platform.  Compared to NGINX, Apache has a larger feature set that can be enabled through the installation of various add-on modules.  Official and non-official modules exist for both Apache and NGINX, but Apache has more available.

Additionally, Apache has supported dynamic loading of these modules, and has for some time now.  This means that all modern modules for Apache are compatible with dynamic loading as well.  NGINX by comparison has only recently added dynamic module support in 2016.  This means not all modules are compatible with dynamic loading yet, but progress has been made toward this end.

Apache has also been around in some form or another for almost 3 decades now.  This means there is a huge amount of resources available to learn from and thus be able to optimize your Apache environment.  Additionally, the official documentation for Apache is some of the best available on the internet.

A Case for NGINX

NGINX was originally designed to meet a challenge of being able to handle at least 10,000 concurrent connections at once from a single server.  This is still feasible with NGINX and an appropriately spec’d server.  As a result it is built in such a way as to be exceptionally efficient at handling static content requests.  This design can also allow NGINX to handle fluctuation in the load amount a bit more gracefully.

The design of NGINX also makes it exceptionally efficient at processing static content requests.  In benchmarks comparing Apache’s performance, NGINX averages around twice as fast to serve static content.  The two are also mostly comparable on dynamic content delivery speeds.

NGINX also has support for a few more items than Apache.  These include media streaming options and reverse-proxy for non-HTTP protocols.  NGINX also has the ability to act as a front-end for another web server.  This would allow one, as an example, to combine the static content performance of NGINX with the module flexibility of Apache.

Which is best for me?

Apache and NGINX are actually quite comparable, with only a few key differences as outlined above that set them apart.  Thus, choosing the best option is not a function of choosing the best web server software, but a function of what you wish to accomplish, and which software fits that best.  If you find your site or application serving mostly static content, it may be a good idea to consider NGINX for the performance gains.  If you require custom modules Apache may be the better choice.  If you have both, you can always live with one or the other, or even combine the two.

Regardless of choice, both web servers have extremely good official documentation and loads of third party advice, guides, and information.  Both have support for various additional features such as load-balancing, modular add-ons, and wide OS compatibility.  Both are also viable choices for most situations.

Installing OpenSSL on Ubuntu

OpenSSL is the de-facto standard for key and CSR generation on a webserver environment.  These CSR’s can then be handed to a Certificate Authority to obtain a SSL certificate to facilitate secure traffic to and from your server.  OpenSSL is free, open source, and secure, so it is the recommended solution to create your CSR’s from.  This article will go through the installation of OpenSSL.

Prerequisites

– A Cloud Server running Ubuntu

Install OpenSSL dependencies

OpenSSL is not installed as a package like most applications, and is instead complied from the source code.  Don’t panic though, this is still relatively easy, all that is required is to have a few things installed to allow the compile to process successfully.  For Ubuntu, this means making sure gcc is installed, as well as the dependencies for OpenSSL itself, namely checkinstall and zlib.  You can install all three with the commands that follow:

sudo apt install build-essential
sudo apt install checkinstall
sudo apt install zlib1g-dev

Download and compile OpenSSL

Next, we need to download the source code for OpenSSL so that it can be compiled. You should check https://www.openssl.org/source/ for the latest version of OpenSSL and make sure you are downloading that. Right click on the link for the latest version .tar file and copy the link location. Next run the following on your server:

cd /usr/local/src/
sudo wget 

This downloads the latest version of OpenSSL into the /usr/local/src/ directory, which is the recommended default location for OpenSSL. Now extract the source code from the .tar file:

sudo tar -xf opnssl-

Please note, replace with the appropriate value based on the version you downloaded.  This guide will use this expression a few more times, so please remember to replace it in each example.

Next, enter the directory you just unpacked:

cd openssl-

Now, configure the install locations for OpenSSL, and then run the compile process:

sudo ./config --prefix=/usr/local/ssl --openssldir=/usr/local/ssl shared zlib
sudo make
sudo make test

This sets the directory for OpenSSL to /usr/local/ssl and creates a shared library with z-compression enabled.  Once so primed, the make commands compile OpenSSL.  Once both make commands complete, OpenSSL is finally ready to install, which you can do by running the following:

sudo make install

Configuring OpenSSL shared libraries

Once OpenSSL is installed, it is prudent to link the shared libraries for it so that they load at runtime.  This can be done by simply adding a config file to /etc/ld.so.conf.d/:

cd /etc/ld.so.conf.d/
sudo vim openssl-.conf

Once inside the text editor add the line to the library file:

/usr/local/ssl/lib

Save and exit the editor, then reload the system dynamic links with the following:

sudo ldconfig -v

You should see the file being loaded in the output, similar to the example below:

sudo ldconfig -v
/usr/lib/x86_64-linux-gnu/libfakeroot:
    libfakeroot-0.so -> libfakeroot-tcp.so
/usr/local/lib:
/usr/local/ssl/lib:
    libssl.so.1.1 -> libssl.so.1.1
    libcrypto.so.1.1 -> libcrypto.so.1.1

Configuring the OpenSSL binary

You will also want to add the binary file for OpenSSL to your PATH variable.  This can be done by editing your environment file:

sudo vim /etc/environment

Inside the text editor add the following to your PATH line, within the parentheses:

:/usr/local/ssl/bin

When finished the line should look similar or the same as the following:

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/local/ssl/bin"

Save and close out of vim.  Next, reload the environment file to bring in the new PATH variable:

source /etc/environment

You can test the changes by echoing the path variable, and test the OpenSSL specifically with which:

echo $PATH
which openssl

You should see results similar to the following:

root@bored-mouse-55:~# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/local/games:/usr/local/ssl/bin
root@bored-mouse-55:~# which openssl
/usr/local/ssl/bin/openssl

Congratulations, OpenSSL is now installed and configured!

Configuring Time Synchronization and Timezone on CentOS 8

To simplify server management across multiple timezones, Cloud Servers default to the universal timezone UTC. In this article we’ll cover how to change your timezone and ensure synchronization is working properly.

In most modern Linux based Operating Systems, the timedatectl command is used to manage time regardless of whether your using ntp, chrony, or systemd-timesyncd. To see the current time, timezone, and time synchronization status, run the timedatectl command with no arguments.

timedatectl

You’ll see your time and timezone in the Local time field:

Local time: Mon 2020-03-01 19:11:29 UTC

You can see that time synchronization is working in the System clock synchronized field:

System clock synchronized: yes

Update timezone

If you need to update your timezone, timedatectl makes it very simple. First, list timezones:

timedatectl list-timezones

Set new timezone:

sudo timedatectl set-timezone America/Chicago

Verify the change with timedatectl:

timedatectl

You’ll see in the Local time field the timezone has been updated:

Local time: Mon 2020-03-02 13:31:16 CST

Configuring Time Synchronization and Timezone on Fedora 31

To simplify server management across multiple timezones, Cloud Servers default to the universal timezone UTC. In this article we’ll cover how to change your timezone and ensure synchronization is working properly.

In most modern Linux based Operating Systems, the timedatectl command is used to manage time regardless of whether your using ntp, chrony, or systemd-timesyncd. To see the current time, timezone, and time synchronization status, run the timedatectl command with no arguments.

timedatectl

You’ll see your time and timezone in the Local time field:

Local time: Mon 2020-03-01 19:11:29 UTC

You can see that time synchronization is working in the System clock synchronized field:

System clock synchronized: yes

Update timezone

If you need to update your timezone, timedatectl makes it very simple. First, list timezones:

timedatectl list-timezones

Set new timezone:

sudo timedatectl set-timezone America/Chicago

Verify the change with timedatectl:

timedatectl

You’ll see in the Local time field the timezone has been updated:

Local time: Mon 2020-03-02 13:31:16 CST

Configuring Time Synchronization and Timezone on Debian 10

To simplify server management across multiple timezones, Cloud Servers default to the universal timezone UTC. In this article we’ll cover how to change your timezone and ensure synchronization is working properly.

In most modern Linux based Operating Systems, the timedatectl command is used to manage time regardless of whether your using ntp, chrony, or systemd-timesyncd. To see the current time, timezone, and time synchronization status, run the timedatectl command with no arguments.

timedatectl

You’ll see your time and timezone in the Local time field:

Local time: Mon 2020-03-01 19:11:29 UTC

You can see that time synchronization is working in the System clock synchronized field:

System clock synchronized: yes

Update timezone

If you need to update your timezone, timedatectl makes it very simple. First, list timezones:

timedatectl list-timezones

Set new timezone:

sudo timedatectl set-timezone America/Chicago

Verify the change with timedatectl:

timedatectl

You’ll see in the Local time field the timezone has been updated:

Local time: Mon 2020-03-02 13:31:16 CST

Configuring Time Synchronization and Timezone on Ubuntu 20.04

To simplify server management across multiple timezones, Cloud Servers default to the universal timezone UTC. In this article we’ll cover how to change your timezone and ensure synchronization is working properly.

In most modern Linux based Operating Systems, the timedatectl command is used to manage time regardless of whether your using ntp, chrony, or systemd-timesyncd. To see the current time, timezone, and time synchronization status, run the timedatectl command with no arguments.

timedatectl

You’ll see your time and timezone in the Local time field:

Local time: Mon 2020-03-01 19:11:29 UTC

You can see that time synchronization is working in the System clock synchronized field:

System clock synchronized: yes

Update timezone

If you need to update your timezone, timedatectl makes it very simple. First, list timezones:

timedatectl list-timezones

Set new timezone:

sudo timedatectl set-timezone America/Chicago

Verify the change with timedatectl:

timedatectl

You’ll see in the Local time field the timezone has been updated:

Local time: Mon 2020-03-02 13:31:16 CST