Analysing log files in Windows and Linux

Everyone knows the scenario, you want to analyze an issue of your server or local computer but where to find all those log files?

In the following tutorial we are going to analyze specific log files in Linux and logs in the Windows Event Viewer. An additional chapter will go through the log analysis via Systemd.

Linux log files

Unfortunately, it is quite different from distribution to distribution, which information can be extracted from specific log files. In the following we will analyze the log file structure of Debian 8 and CentOS 7.2. The first location to look for log files should always be /var/log/. Depending on their configuration, Apache, Nginx or similar applications write log files to this folder too. System log specifications and locations can be found in the file /etc/rsyslog.conf.

Debian 8:

  • /var/log/auth.log

Logs of successful and failed authentications to your system can be found in this log file. It is also logged when a user invokes commands via sudo.

  • /var/log/messages

This file contains log entries of general system information, amongst others, you will also find the system upstart logs.

  • /var/log/dmesg or dmesg

The kernel ring buffer can be read with dmesg. You will find information about the system upstart, runtime kernel module messages and many further messages according to the hard and software of your system. By default, dmesg shows the full ring buffer. However, the output can be customized by adding specific parameters. A thorough documentation can be found on the manual page (man dmesg).

  • /var/log/syslog

This is one of the most important log files in general. Every Linux process is free to log to the syslog by implementing the syslog interface. It also logs the system upstart and executed cron-jobs.

CentOS 7.2:

As the log file structure is quite similar to the one of Debian 8, we will just mention the differences.

  • /var/log/secure

This log file is the equivalent to /var/log/auth.log in Debian systems. All kind of authentications are logged here.

  • /var/log/messages

There is no separation of /var/log/messages and /var/log/syslog in CentOS, all system logs of processes which implement the syslog interface can be found here.

  • /var/log/cron

Cron specific log files are not part of the syslog as in Debian. They can be found in the above mentioned file.


Log analysis via Systemd

Systemd is basically the standard Init system of nearly all major Linux distributions today. Since at least April 2015, when Debian and Ubuntu switched to Systemd, every Linux administrator or user has been in touch with Systemd. As Systemd is a complex system, we will only take a look into the log analysis functionality provided. Every process in Systemd is identified as a unit. All active units can be shown via the following command:

systemctl list-units

When appending the parameter --all, this command also shows all inactive units.

Logs being created by Systemd are managed in the so called Journal. These logs can be accessed via the journalctl binary. If journalctl is called without any parameter, it will print out the whole Journal. However, it is also possible to output the log entries of specific units only. In the following example, we are going to analyze the log files of the Apache web server.

journalctl -u httpd

It is also possible to restrict the output with the parameters --since and --until.

journalctl -u httpd --since "2016-11-01 20:00:00" --until "2016-11-03 20:00:00"

The above command will output the Apache log entries between 2016-11-01 20:00:00 and 2016-11-03 20:00:00. It is also possible to use keywords like "today" or "yesterday".

You can also output the log files of more than one unit at the same time. In the following example we will output all Apache and Nginx log entries which have been logged since yesterday.

journalctl -u httpd -u nginx --since yesterday

If the parameter -f is used, all desired log entries are shown in real time.

The above was only a slight view into the possibilities of journalctl, there are several other useful features which are described on the manual page (man journalctl).


Log analysis via Windows Event Viewer

Windows Event Viewer Overview

In the above picture in the left navigation you can see the entry "Windows Logs". The following entries are most important.

  • Application

This entry will show the events of locally installed applications.

  • Security

Here you can see successful and failed login attempts.

  • System

This entry logs operating system internal events and errors.

Via the entry "Custom Views" -> "Server Roles" -> "Remote Desktop Services" you can see RDP related events and errors.

Potential hardware issues can be identified via "Application and Service Logs" -> "Hardware Events".

Useful for error analysis can also be the overview which can be seen via "Overview and Summary" -> "Summary of Administrative Events", it provides a summarized overview of the system status in general.


Manage Windows Updates in Windows 2016

In Windows Server 2016, the administration of the (automatic) Windows Updates has changed slightly. The following tutorial will show you how to check and manage the Windows updates for your Windows Server 2016 system.

1. Please connect to your server using RDP and open the Settings App via the Start menu.

Afterwards you can click on "Update & Security" which will forward you to the following screen.

Everything regarding updates can be done via this screen.

You have the option to "Check for updates", which will check for the latest updates and automatically download and install them. If some updates require a reboot, Windows will schedule it accordingly.  It is possible to set "active hours" from the link "Change active hours" where a time frame can be given in which Windows shall not reboot the device automatically.

It is further possible to set a custom day and time for the reboot via the link "Restart options".

The link "Update history" provides an overview about recent updates where it is possible to uninstall recent updates and to check further recovery options.

The link "Advanced options" provides you with the option to also update other Microsoft products through Windows updates and to "Defer feature updates", which is described by Microsoft as follows:  "When you defer upgrades, new Windows features won't be downloaded or installed for several months. Deferring upgrades doesn't effect security updates. Note that deferring upgrades will prevent you from getting the latest Windows features as soon as they're available".

The link "Privacy settings" will forward you to the general privacy settings of Windows.

Posted by: Dirk | Tagged as: , , , 2 Comments

Let’s Encrypt!

In times when data security is an important topic, encryption is a vital part of it. Unfortunately, in most cases, it is a complex task which many users are not able to handle properly due to the lack of expert knowledge in this field. To secure a website via Secure Socket Layer (SSL) or Transport Layer Security (TLS) for being accessible via Hypertext-Transfer-Protocol Secure (HTTPS), a certificate is needed.

Encrypted connections are based on certificates, if a user is accessing a website via HTTPS, an encrypted connection is being established. Before this encrypted connection can be established successfully, the certificate provided by the accessed server is being verified if it can be trusted. This verification of trust is basically done as follows:

  1. Signature verification of the certificate based on the chain of trust
  2. Verification if the accessed domain corresponds to the domain which is valid according to the certificate

What is this chain of trust all about?

In general every operating system and even browsers like Firefox or Google Chrome come with pre-installed certificates from trusted certificate authorities (CAs). These certificates are always trusted if they are not revoked in the meantime. The chain of trust verification basically verifies, if the signature of the certificate in question is already trusted by the pre-installed certificates of the trusted certificate authorities. It is called chain of trust as it is for example possible, that the signature of Let's Encrypt is not trusted on your system but the certificate which is used by Let's Encrypt in order to sign your certificate is also signed with a certificate of a third trusted certificate authority which is trusted on your system. Therefore Let's Encrypt guarantees that your certificate can be trusted and the third certificate authority, which is trusted on your system, guarantees that Let's Encrypt can be trusted as well.

How does the Let's Encrypt project differ to other certificate authorities?

As establishing and running a trusted certificate authority is expansive, normally a fee has to be paid in order to have your certificate being signed from a trusted certificate authority. Let's Encrypt did establish a trusted certificate authority which offers the signing of certificates for free and aims to improve and automate the process of certificate creation and installation in general. The main idea behind this project is to create a more secure and privacy respecting web.

Free certificates with our Webspace Packages

As we already informed you with the post Webspace: Free SSL certificates available now!, domains added via our Webspace Packages are already equipped with a Let's Encrypt signed certificate. Even the renewal of the certificates is handled completely automatically.

Let's Encrypt via AutoSSL in cPanel

Since cPanel & WHM Version 58.0.17, Let's Encrypt is officially supported by cPanel. Currently it is necessary to integrate it via shell by invoking the installation script located at:


as root user.

After successful installation it is possible to choose Let's Encrypt as the default certificate provider via Home >> SSL/TLS >> Manage AutoSSL.
autossl_lets_encrypt Specific user settings can be done via the "Manage Users" tab.

Let's Encrypt via extension in Plesk

Also Plesk in versions 12.5 and later supports Let's Encrypt by an extension. The installation and configuration steps in this tutorial work for both Linux and Windows installations.

To install the extension, please go in Plesk to:

"Tools & Settings" >> in the area "Plesk" >> "Updates & Upgrades"

A new tab is opening. Eventually you have to confirm a self signed certificate for this site in your browser. On the site, please choose "Add/Remove Components".


Please mark the extension for installation like in the picture above and start the installation with "Continue". The installation finishes with the message "All operations with products and components have been successfully completed.". With a click on "OK" you will come back to the main menu. You can close the browser tab then.
Now you have to request the certificate and activate it for the domain. To do so, please change to "Websites & Domains" and choose "Show more" to increase the available list of options for your domain. As you can see, there is now an additional option for Let's Encrypt.


Please open this link and check the e-mail address. Consider if the site should be available over www too and if necessary, set the tick at "include www.yourdomain.com as an alternative domain name.". With a click on "OK", you will start the request for the certificate. When the process has finished, your site should already be reachable over https. To be on the safe side, you can now go to the the "Hosting Settings" of your domain and check in the area "Security" the option "Permanent SEO-safe 301 redirect from HTTP to HTTPS". This will prevent unencrypted connections to your website. In the option below you can choose the just ordered certificate manually to be used for your site if has not been chosen automatically.

If there was an error shown during the certificate request, please check if the A record of your domain is pointing to the IP address of your server. This also applies to the subdomain with www.

Let's Encrypt usage without an Administration Panel (Debian 8)

The usage of Certbot is recommended together with Let's Encrypt. We are using the Apache webserver and the operating system Debian 8 for our example.

In order to install Certbot together with all dependencies, the following commands have to be executed as root user:

# Activate Debian Jessie backports repository

echo "deb http://ftp.debian.org/debian jessie-backports main" >> /etc/apt/sources.list && apt-get update


# Installation of Certbot

apt-get install python-certbot-apache -t jessie-backports


After the installation it is possible to automatically generate signed certificates for your domains via Certbot. The certificates will be configured automatically within your Apache webserver too. The following command invokes a configuration dialogue which is asking for information like domain name(s) and your e-mail address. After submitting the required information and agreeing to the terms of service of Let's Encrypt, your signed certificate(s) will be created and configured within Apache. It is also possible to decide whether your domain shall be accessible via HTTP and HTTPS or if HTTPS connections shall be forced.

# Starting the automated configuration dialogue

certbot --apache

If you desire to configure your certificate(s) on your own, the following command can be used for creating the signed certificate(s) only.

# Creation of certificate(s) only

certbot --apache certonly

Certbot does not only support Apache with Debian 8 as operating system, there are several combinations of webservers and operating systems possible which can be seen via the following link: Certbot.

Let's Encrypt installation without Administration Panel (CentOS 7.2)

As the usage of Certbot on CentOS does not differ from the usage on Debian 8, we are just taking a short look into the installation of Certbot on CentOS. As the Apache/httpd default package (yum install httpd) on CentOS does not include the SSL module, you need to make sure to have this module installed before installing Certbot.

# Installation of Extra Packages for Enterprise Linux and optionally mod_ssl

yum install epel-release mod_ssl 

# Installation of Certbot

yum install python-certbot-apache


Configuration of an automated certificate renewal

Since Let's Encrypt certificates are only valid for three months, it is vital to configure an automated renewal.

As the Certbot package of Debian 8 already configures a cron-job for the certificate renewal we are going to show you how the cron-job can also be configured for a standard CentOS installation.

# /etc/cron.d/certbot


0 */12 * * * root test -x /usr/bin/certbot && perl -e 'sleep int(rand(3600))' && certbot -q renew


This cron-job runs every 12 hours and triggers the renewal of all your certificates, if they will expire in less than 30 days. It is recommended to leave this value of twice a day as this will help recognizing that a certificate has been revoked.



Posted by: Dirk | Tagged as: , , , No Comments