Category: Linux

In one of our previous articles, we learnt how you can encrypt your entire root filesystem on Linux easily.

However, in some cases, you may want to encrypt one simple partition that may store some of your important files.

As you already know, encrypting your disks is crucial. If your laptop were to be stolen, you would probably lose all your personal information.

However, there are some ways for you to cope with this problem : by encrypting your disk partitions.

In this tutorial, you will learn about all the steps necessary to encrypt an entire disk partition, secure it with a passphrase or with a keyfile.

For the example, the article will be illustrated on a RHEL 8 operating system, but there should not be any differences if you use another one.

• Fdisk Command in Linux (Create Disk Partitions)
• Understanding Processes on Linux | Types of Process in Linux | Creating, Listing, Monitoring, Changing Linux Processes
• The Definitive Guide to Centralized Logging with Syslog on Linux

Prerequisites

In order to execute most of the commands provided in this article, you need to have administrator rights.

To check whether this is the case or not, you can execute the “groups” command and verify that you belong to the “sudo” group for Debian-based distributions or “wheel” for RedHat based ones.

$ groups

If you don’t have such rights, you can read one of our articles on the subject about getting sudo rights for Ubuntu or CentOS distributions.

Encrypt Partition using cryptsetup

As specified in the previous articles, encrypting a partition involves formatting the entire disk.

As a consequence, if you plan on encrypting a disk with existing data, you should now that your data will be erased in the process. To avoid losing anything, you should make a backup of your data on an external disk or in an online cloud.

Create New Partition on disk

In order to encrypt a partition, we are going first to create a new one using the “fdisk” utility. For the example, we are going to create a new partition named “sdb1” on the “sdb” disk.

$ sudo fdisk /dev/sdb

In the fdisk utility, you can create a new partition using the “n” keyword and specify that you want a partition with a size of 5 GBs for example.

If you are not sure about how to use “fdisk” or how to create partitions, we have a dedicated article about this subject.

At the end of the process, you need to use the “w” keyword in order to write the changes to the disk.

Awesome, now that your partition is created, we are going to format it as a LUKS partition.

Format Disk Partition as LUKS

To encrypt the partition, we are going to use a command related to the LUKS project.

The LUKS project, short for Linux Unified Key System, is a specification used in order to encrypt all storage devices using special cryptographic protocols. As described, LUKS is only a specification, you will need a program that implements it.

In this case, we are going to use the “cryptsetup” utility. As explained in the manual section, cryptsetup aims at creating encrypted spaces for dm-crypt.

First of all, make sure that you have the “cryptsetup” command using the “which” command.

$ which cryptsetup

If the cryptsetup cannot be found on your server, make sure to install it using one of the following commands

$ sudo apt-get install cryptsetup                     (for Debian distributions)

$ sudo yum install cryptsetup                         (for RHEL/CentOS distributions)

To create your LUKS partition, you need to execute the “cryptsetup” followed by “luksFormat” and the name of the partition to be formatted.

$ sudo cryptsetup luksFormat /dev/sdb1

First of all, you are reminded that encrypting your disk will actually format it in the process.

After typing “YES” in capital letters, you will have to choose a passphrase in order to secure your device.

LUKS supports two ways of protecting your media : using a passphrase (the one that we currently use) and using keys. For now, you can choose a safe password and your partition should be formatted automatically.

Now that your partition is created, you can inspect it using the “lsblk” command : the partition should be marked as “crypto_luks“.

$ lsblk -f

Awesome! Now that the volume is formatted, we can open it and create a simple ext4 filesystem on it.

Create ext4 Filesystem on Partition

By default, your encrypted volume is closed meaning that you cannot access data that is available on it.

In order to “open”, meaning “unlocking” your volume, you have to use the “cryptsetup” command again followed by “luksOpen” and the name of the volume.

At the end of the command, provide a name for your open volume, in this case we are going to choose “cryptpart“.

$ sudo cryptsetup luksOpen /dev/sdb1 cryptpart

As you can guess, you are asked to provide the passphrase that you chose in the previous section.

Running the “lsblk” command again, you probably noticed that one volume was created under the “sdb1” encrypted volume named “cryptpart“. The “device mapper”, which is one of the frameworks of the Linux Kernel, did that for you.

Now that your volume is unlocked, it is time for you to create a new ext4 filesystem on it.

To create a new filesystem on your partition, use the “mkfs” command followed by the filesystem format, in this case “ext4”.

$ sudo mkfs.ext4 /dev/mapper/cryptpart

Awesome, the filesystem was created.

You can now mount it and add new files to it. Files created on this volume will automatically be encrypted.

$ mkdir -p /home/devconnected/files 

$ sudo mount /dev/mapper/cryptpart /home/devconnected/files

$ sudo chown devconnected:devconnected /home/devconnected/files

Awesome, now that your data is safe on an encrypted partition, let’s see how you can mount the encryption partition on boot.

Modify crypttab and fstab files

Many system administrators know the existence of the fstab file that is used by your init process to mount drives.

However, when dealing with encrypted partitions, there is another file that comes into play : /etc/crypttab.

Similarly to the fstab file, crypttab is read by your init process when booting. Given the information provided in it, it will ask you to unlock the partition or it will read a key file in order to do it automatically.

Note : the /etc/crypttab may not exist on your system. If it is not the case, you may have to create it.

The columns of the crypttab are described above :

• Device name : you can give your decrypted device any name that you want. Furthermore, it will be automatically created by the device mapper under the “/dev/mapper” path. In the previous section, we chose “cryptpart” for this column;
• Encrypted device UUID : in order to find which partition contains the encrypted data, your system needs to have its UUID meaning its unique identifier;
• Method of authentication : as explained, you can choose “none” for the passphrase or you can specify a path to the key. The key method will be explained in the last chapter of this article;
• Mount options : using this column, you can specify the number of tries for a passphrase, the cipher, the encryption method and many other parameters. The complete list of options is available in the “crypttab” manual page.

$ sudo nano /etc/crypttab

# Content of the crypttab file
cryptpart    UUID=<partition_uuid>    none    luks

If you have doubts about the UUID of your encrypted partition, you can use the “blkid” command with a simple “grep” pipe.

$ sudo blkid | grep -i luks

Now that the “/etc/crypttab” file is modified, you will have to modify the “fstab” file to specify the mountpoint.

$ sudo blkid | grep -i ext4

$ sudo nano /etc/fstab

In the fstab columns, you have to specify :

• The decrypted device UUID : in order to find it, you can use the “blkid” command but make sure that you opened the device before proceeding. If the device is closed, you won’t be able to find your UUID;
• The mount point : where the decrypted device is going to be mounted. If the path does not exist, it is going to be created automatically;
• The filesystem type : in this case, we chose to use “ext4” but it may be different on your system;
• Dump and pass options : we don’t want the filesystem to be checked on boot-time, so we can keep it to the default values.

When you are done, save your file and you should be good to go.

Given the steps you just performed, your device is ready and it should automatically be mounted on boot.

Verify encrypted device mounting on boot

In order to verify that the device is correctly mounted, we can restart our server and wait for the initramfs module to open the encrypted device.

$ sudo reboot

This is the screen that you should see, at least on RHEL8, when starting your server. If you provide the passphrase, your machine should be able to unlock it and mount it for you.

Once you are logged in your server, you can check that the encrypted partition was correctly mounted using the “lsblk” once again.

$ lsblk -f | grep sdb1 -A 2

Congratulations, you successfully encrypted a partition on Linux using LUKS!

Create Keys For Encrypted Partition

As explained before, LUKS handles two authentication methods, namely passphrases and key files.

In the previous section, we used passphrases but it can be quite handy for you to also have a authentication key.

First of all, create a key file and store it somewhere safe (in directories that regular users cannot navigate to, like “/boot” or “/root“).

$ echo "supersecretpass" > volume-key

$ sudo mv volume-key /boot/

As you can see, by default, the file was created using the user credentials and it has too many permissions.

Using the “chown” and “chmod” commands, we can set “root” as the owner of the file and change its permissions to read-only.

$ sudo chown root:root /boot/volume-key

$ sudo chmod 0400 /boot/volume-key

Now that the file is set to read-only, we can add it as a key in one of the slots of our LUKS volume.

Add Key to LUKS Volume

In order to add a key to your LUKS volume, you need to execute the “cryptsetup” command followed by the “luksAddKey”, the name of the encrypted volume and the path to the key.

$ sudo cryptsetup luksAddKey <encrypted_device> <path_to_key>

$ sudo cryptsetup luksAddKey /dev/sdb1 /boot/volume-key

In order to perform this operation, you will be prompted for your passphrase. When provided, the key will be automatically added to your keyslots.

To verify that the key was correctly added, you can inspect your keyslots using the “luksDump” command.

$ sudo cryptsetup luksDump /dev/sdb1

Now that the key is added, you only need to modify the “/etc/crypttab” in order for your system to find it on boot.

$ sudo nano /etc/crypttab

# Content of the crypttab file
cryptpart    UUID=<partition_uuid>    /boot/volume-key    luks

When rebooting, your encrypted partition will be mounted automatically!

Conclusion

In this article, you learnt how you can easily encrypt your partition on Linux using the LUKS project and its implementation named cryptsetup.

You can saw that you can use a “key file” in order for your partition to be unlocked automatically.

If you are interested in a full system encryption, we recently wrote an article on the subject.

Also, if you want to read more about Linux System Administration, make sure to have a look at our dedicated section on the website.

DNS, short for the Domain Name System protocol, is used on Linux systems in order to retrieve IP addresses associated with names.

For example, when you are performing a ping request, it is quite likely that you are using the DNS protocol to retrieve the server IP.

In most cases, the DNS requests that you perform are stored in a local cache on your operating system.

However, in some cases, you may want to flush the DNS cache of your server.

It might be because you changed the IP of a server on your network and you want to changes to be reflected immediately.

In this tutorial, you are going to learn how you can easily flush the DNS cache on Linux, whether you are using systemd or dnsmasq.

• Tcpdump Command in Linux
• The Definitive Guide to Centralized Logging with Syslog on Linux
• Syslog: The Complete System Administrator Guide

Prerequisites

In order to be able to flush your DNS cache, you have to know how DNS resolution works on your Linux system.

Depending on your distribution, you may be facing different Linux services that act as a DNS resolver.

Before you start, it is quite important for you to know how DNS resolution will actually happen on your operating system.

Inspired by this Wikipedia diagram
If you are reading this article, you are looking to flush the cache of your local DNS resolver. But as you can see, there are many different caches from your local application until the actual Internet DNS servers.

In this tutorial, we are going to focus on the yellow box meaning the local stub resolver implemented on every Linux system.

Finding your local DNS resolver

On most Linux systems, the DNS resolver is either “systemd-resolved” or dnsmasq. In order to know if you are dealing with one or another, you can execute the following command

$ sudo lsof -i :53 -S

Note : so why are we running this command? As DNS runs on port 53, we are looking for the commands associated with the service running on port 53, which is your local DNS resolver or “stub”.

As you can see, on a recent Ubuntu 20.04 distribution, the service listening on port 53 is systemd-resolved. However, if you were to execute this command on Ubuntu 14.04, you would get a different output.

In this case, the local DNS used in dnsmasq and commands are obviously different.

Knowing this information, you can go the chapter you are interested in. If you were to have a different output on your server, make sure to leave a comment for us to update this article.

Flush DNS using systemd-resolved

The easiest way to flush the DNS on Linux, if you are using systemd-resolved, is to use the “systemd-resolve” command followed by “–flush-caches”.

Alternatively, you can use the “resolvectl” command followed by the “flush-caches” option.

$ sudo systemd-resolve --flush-caches

$ sudo resolvectl flush-caches

In order to verify that your Linux DNS cache was actually flushed, you can use the “–statistics” option that will highlight the “Current Cache Size” under the “Cache” section.

$ sudo systemd-resolve --statistics

Congratulations, you successfully flushed your DNS cache on Linux!

Flush DNS cache using signals

Another way of flushing the DNS cache can be achieved by sending a “USR2” signal to the “systemd-resolved” service that will instruct it to flush its DNS cache.

$ sudo killall -USR2 systemd-resolved

In order to check that the DNS cache was actually flushed, you can send a “USR1” signal to the systemd-resolved service. This way, it will dump its current state into the systemd journal.

$ sudo killall -USR1 systemd-resolved

$ sudo journalctl -r -u systemd-resolved

Awesome, your DNS cache was correctly flushed using signals!

Flush DNS using dnsmasq

The easiest way to flush your DNS resolver, when using dnsmasq, is send a “SIGHUP” signal to the “dnsmasq” process with the “killall” command.

$ sudo killall -HUP dnsmasq

Similarly to systemd-resolved, you can send a “USR1” to the process in order for it to print its statistics to the “syslog” log file. Using a simple “tail” command, we are able to verify that the DNS cache was actually flushed.

Now what if you were to run dnsmasq as a service?

Dnsmasq running a service

In some cases, you may run “dnsmasq” as a service on your server. In order to check whether this is the case or not, you can run the “systemctl” command or the “service” one if you are on an SysVinit system.

$ sudo systemctl is-active dnsmasq

# On SysVinit systems
$ sudo service dnsmasq status

If you notice that dnsmasq is running as a service, you can restart it using the usual “systemctl” or “service” commands.

$ sudo systemctl restart dnsmasq

# On SysVinit systems
$ sudo service dnsmasq restart

After running those commands, always make sure that your services were correctly restarted.

$ sudo systemctl status dnsmasq

# On SysVinit systems
$ sudo service dnsmasq status

Conclusion

In this tutorial, you learnt how you can quickly and easily flush your DNS cache on Linux.

Using this article, you can easily clear the cache for systemd and dnsmasq local resolvers. However, you should know that there is another common DNS, named bind, that is purposefully omitted in this article.

Another article about setting up a local DNS cache server using BIND should come in the near future.

If you are interested in DNS queries and how they are performed, you can use this very useful article from “zwischenzugs” named the “Anatomy of a DNS query“. The article is particularly useful if you want to debug DNS queries and you wonder how they are performed.

Also if you are interested in Linux System Administration, we have a complete section about it on the website, so make sure to check it out.

Whether you are an experienced system administrator or just a regular user, you have probably already mounted drives on Linux.

Drives can be local to your machine or they can be accessed over the network by using the NFS protocol for example.

If you chose to mount drives permanently, you have probably added them to your fstab file.

Luckily for you, there is a better and more cost effective way of mounting drives : by using the AutoFS utility.

AutoFS is a utility that mount local or remote drives only when they are accessed : if you don’t use them, they will be unmounted automatically.

In this tutorial, you will learn how you can install and configure AutoFS on Linux systems.

Prerequisites

Before starting, it is important for you to have sudo privileges on your host.

To verify it, simply run the “sudo” command with the “-v” option : if you don’t see any options, you are good to go.

$ sudo -v

If you don’t have sudo privileges, you can follow this tutorial for Debian based hosts or this tutorial for CentOS based systems.

• How To Install Samba on Debian 10 Buster
• How To Install Docker on Ubuntu 18.04 & Debian 10
• How To Encrypt Partition on Linux

Installing AutoFS on Linux

Before installing the AutoFS utility, you need to make sure that your packages are up-to-date with repositories.

$ sudo apt-get update

Now that your system is updated, you can install AutoFS by running the “apt-get install” command with the “autofs” argument.

$ sudo apt-get install autofs

When installing the AutoFS package, the installation process will :

• Create multiple configuration files in the /etc directory such as : auto.master, auto.net, auto.misc and so on;
• Will create the AutoFS service in systemd;
• Add the “automount” entry to your “nsswitch.conf” file and link it to the “files” source

Right after the installation, make sure that the AutoFS service is running with the “systemctl status” command

$ sudo systemctl status autofs

You can also enable the AutoFS service for it to be run at startup

$ sudo systemctl enable autofs

Now that AutoFS is correctly installed on your system, let’s see how you can start creating your first map.

How AutoFS works on Linux

“Maps” are a key concept when it comes to AutoFS.

In AutoFS, you are mapping mount points with files (which is called an indirect map) or a mount point with a location or a device.

In its default configuration, AutoFS will start by reading maps defined in the autofs.master file in the /etc directory.

From there, it will start a thread for all the mount points defined in the map files defined in the master file.

Starting a thread does not mean that the mount point is mounted when you first start AutoFS : it will only be mounted when it is accessed.

By default, after five minutes of inactivity, AutoFS will dismount (or unmount) mount points that are not used anymore.

Note : configuration parameters for AutoFS are available in the /etc/autofs.conf

Creating your first auto map file

Now that you have an idea on how AutoFS works, it is time for you to start creating your very first AutoFS map.

In the /etc directory, create a new map file named “auto.example“.

$ sudo touch /etc/auto.example

The goal of this map file will be to mount a NFS share located on one computer on the network.

The NFS share is located at the IP 192.168.178.29/24 on the local network and it exports one drive located at /var/share.

Before trying to automount the NFS share, it is a good practice to try mounting it manually as well as verifying that you can contact the remote server.

$ ping 192.168.178.29

Creating a direct map

The easiest mapping you can create using AutoFS is called a direct map or a direct mapping.

A direct map directly associates one mount point with a location (for example a NFS location)

As an example, let’s say that you want to mount a NFS share at boot time on the /tmp directory.

To create a direct map, edit your “auto.example” file and append the following content in it :

# Creating a direct map with AutoFS

# <mountpoint>    <options>    <remote_ip>:<location>   

/tmp              -fstype=nfs  192.168.178.29:/var/share

Now, you will need to add the direct map to your “auto.master” file.

To specify that you are referencing a direct map, you need to use the “-” notation

# Content of the auto.master file

/-    auto.example

Now that your master file is modified, you can restart the AutoFS service for the changes to be effective.

$ sudo systemctl restart autofs

$ cd /tmp

Congratulations, you should now be able to access your files over NFS via direct mapping.

Creating an indirect mapping

Now that you have discovered direct mappings, let’s see how you can use indirect mappings in order to mount remote location on your filesystem.

Indirect mappings use the same syntax as direct mappings with one small difference : instead of mounting locations directly to the mountpoint, you are mounting it in a location in this mountpoint.

To understand it, create a file named “auto.nfs” and paste the following content in it

nfs    -fstype=nfs  192.168.178.29:/var/share

As you can see, the first column changed : in a direct map, you are using the path to the mountpoint (for example /tmp), but with an indirect map you are specifying the key.

The key will represent the directory name located in the mount point directory.

Edit your “auto.master” file and add the following content in it

/tmp   /etc/auto.nfs

Restart your AutoFS service and head over to the “tmp” directory

$ sudo systemctl restart autofs

$ cd /tmp

By default, there won’t be anything displayed if you list the content of this directory : remember, AutoFS will only mount the directories when they are accessed.

In order for AutoFS to mount the directory, navigate to the directory named after the key that you specified in the “auto.nfs” file (called “nfs” in this case)

$ cd nfs

Awesome!

Your mountpoint is now active and you can start browsing your directory.

Mapping distant home directories

Now that you understand a bit more about direct and indirect mappings, you might ask yourself one question : what’s the point of having indirect mapping when you can simply map locations directly?

In order to be useful, indirect maps are meant to be used with wildcard characters.

One major use-case of the AutoFS utility is to be able to mount home directories remotely.

However, as usernames change from one user to another, you won’t be able to have a clean and nice-looking map file, you would have to map every user in a very redundant way.

# Without wildcards, you have very redundant map files

/home/antoine  <ip>:/home/antoine
/home/schkn    <ip>:/home/schkn
/home/devconnected <ip>:/home/devconnected

Luckily for you, there is a syntax that lets your dynamically create directories depending on what’s available on the server.

To illustrate this, create a new file named “auto.home” in your /etc directory and start editing it.

# Content of auto.home

*    <ip>:/home/&

In this case, there are two wilcards and it simply means that all the directories found in the /home directory on the server will be mapped to a directory of the same name on the client.

To illustrate this, let’s pretend that we have a NFS server running on the 192.168.178.29 IP address and that it contains all the home directories for our users.

# Content of auto.home

*   192.168.178.29:/home/&

Save your file and start editing your auto.master file in order to create your indirect mapping

$ sudo nano /etc/auto.master

# Content of auto.master

/home     /etc/auto.home

Save your master file and restart your AutoFS service for the changes to be applied.

$ sudo systemctl restart autofs

Now, you can head over to the /home directory and you should be able to see the directories correctly mounted for the users.

Note : if you see nothing in the directory, remember that you may need to access the directory one time for it to be mounted by AutoFS

Mapping and discovering hosts on your network

If you paid attention to the auto.master file, you probably noticed that there is an entry for the /net directory with a value “-hosts“.

The “-hosts” parameter is meant to represent all the entries defined in the /etc/hosts file.

As a reminder, the “hosts” file can be seen as a simple and local DNS resolver that associates a set of IPs with hostnames.

As an example, let’s define an entry for the NFS server into the /etc/hosts file by filling the IP and the hostname of the machine.

First of all, make sure that some directories are exported on the server by running the “showmount” command on the client.

$ sudo showmount -e <server>

Now that you made sure that some directories are exported, head over to your “auto.master” file in /etc and add the following line.

# Content of auto.master

/net   -hosts

Save your file and restart your AutoFS service for the changes to be applied.

$ sudo systemctl restart autofs

That’s it!

Now your NFS share should be accessible in the /net directory under a directory named after your server hostname.

$ cd /net/<server_name>

$ cd /net/<server_ip>

Note : remember that you will need to directly navigate in the directory for it to be mounted. You won’t see it by simply listing the /net directory on the first mount.

Troubleshooting

In some cases, you may have some troubles while setting up AutoFS : when a device is busy or when you are not able to contact a remote host for example.

• mount/umount : target is busy

As Linux is a multi-user system, you might have some users browsing some locations that you are trying to mount or unmount (using AutoFS or not)

If you want to know who is navigating the folder or who is using a file, you have to use the “lsof” command.

$ lsof +D <directory>
$ lsof <file>

Note : the “+D” option is used in order to list who is using the resource recursively.

• showmount is hanging when configuring host discovery

If you tried configuring host discovery by using the “-hosts” parameter, you might have verified that your remote hosts are accessible using the “showmount” command.

However, in some cases, the “showmount” command simply hangs as it is unable to contact the remote server.

Most of the time, the server firewall is blocking the requests made by the client.

If you have access to the server, you try to inspect the logs in order to see if the firewall (UFW for example) is blocking the requests or not.

$ sudo journalctl -u autofs.service

$ sudo systemctl stop autofs

$ sudo automount -f -v

As a network administrator, you are probably already very familiar with the ARP protocol.

ARP is commonly used by layer two devices in order to discover as well as communicating with each other easily.

When you are dealing with a small office network, you might be tempted to ping hosts in order to verify that they are available.

If you are using the ICMP protocol, you might be aware that you are actually performing ARP requests in order to probe devices on your network.

If you are looking for a more straightforward way to create ARP pings, you might be interested in the arping command.

In this tutorial, we are going to focus on the arping command : how to install it and how to use it effectively.

Prerequisites

In order to install the arping command on your system, you will obviously need sudo privileges on your server.

In order to check if you are sudo or not, you can simply execute the following command

$ groups

user sudo

If this is not the case, you can read our guide on getting sudo privileges for Debian or CentOS hosts.

• Tcpdump Command in Linux
• How To Add A User to Sudoers On CentOS 8 | Centos 8 Add User to Group
• How To Install Prometheus with Docker on Ubuntu 18.04

In order to install the arping command on your server, execute the “apt-get install” command and specify the “arping” package.

$ sudo apt-get install arping

Now that the command is installed, you can execute the “arping” command in order to check the current version used.

$ arping -v

ARPing 2.19, by Thomas Habets <thomas@habets.se>

Great!

The arping command is now installed on your server.

By default, the arping command is going to send an ARP (or ICMP) request every second, but it can obviously be configured.

Using arping to discover hosts

First of all, as any device communicating over Ethernet, your device has an internal ARP table used to communicate over the network.

In order to see your current ARP entries, you can simply execute the “arp” command with the “-a” option for all devices.

$ arp -a

When using the ARP command, you are presented with a list of hostnames, followed by IPs and MAC addresses.

In this case, I am presented with the only entry in my ARP table : a router accessible via the 192.168.178.1 IP address.

However, I might be interested in finding other hosts on my local network : to achieve that, you are going to use the arping command.

Pinging hosts using IP addresses

In order to ping hosts over your network, you can simply use the “arping” command and specify the IP address to be pinged.

Additionally, you can specify the number of pings to be sent using the “-c” option for “count”.

$ arping -c 2 <ip_address>

Note : if you are not sure about the way of finding your IP address on Linux, we have a complete guide on the subject.

For example, using the “192.168.178.27” IP address over your local network, you would execute the following command

As you can see, if you are getting response pings, you are presented with the MAC address of the corresponding device.

Note that using the arping command will not automatically update your ARP table : you would have to use a command such as ping in order to update it.

$ arp -a

Awesome, you successfully used the arping command in order to issue ARP requests over the network!

ARP timeouts using arping

If the arping command is not able to resolve the IP address of the target defined, you will get an ARP timeout.

As an example, executing an ARP request on an unknown host would give you the following output

$ arping -c 5 <ip_address>

As you can see, in some cases, you will be presented with a warning if you don’t specify any network interface.

This is quite normal because the arping command expects a network interface to be specified.

If you were to deal with a router, or if you chose to install your Linux server as a router, two network interface cards can be installed in order to route to two different networks.

If this is the case, the arping needs to know the network interface it needs to use in order to send the ARP ping.

As you can see, the arping command will try to “guess” the network interface if it is not provided with one.

Specifying the network interface

If you have multiple network interfaces on your server, the arping won’t be able to “guess” the network interface card to be used.

As a consequence, you might get an error message stating that the arping was not able to guess the correct one.

In order to specify the network interface to be used, you will have to use the “-I” option followed by the name of the network interface.

If you need some help on how to enumerate network interfaces, you can use this guide on finding your IP address on Linux.

$ arping -I <interface_name> <ip_address>

If our interface is named “enp0s3”, the command would be the following one :

$ arping -I enp0s3 192.168.178.22

Awesome, you have pinged your distant server and you have specified the network interface to be used!

Sending ARP pings from Source MAC

In some cases, you may want to specify the source MAC address you are sending packets from.

In order to achieve that, you need to execute the “arping” command with the “-s” option for “source” followed by the MAC address you want to ping.

$ arping -c 2 -s 00:60:70:12:34:56 <ip_address>

In this case, you have two possibilities :

• You are the owner of the MAC address and you can simply use the “-s” option.
• You are not the owner of the MAC address and you are trying to spoof the MAC address. In this case, you need to use the promiscuous mode. As a short reminder, the promiscuous mode is set to transmit all frames received by the NIC rather than the ones it was meant to receive.

In order to enable the promiscuous mode with the “arping” command, you need to use the “-p” option.

Using the options we used previously, this would lead us to the following command.

$ arping -c 2 -s 00:60:70:12:34:56 -p <ip_address>

Conclusion

In this tutorial, you learnt how you can easily use the arping in order to ping IP addresses on your local network.

Using arping, you are able to populate your local ARP cache with the matching MAC address.

You also learnt that you are able to “spoof” your MAC address by using the promiscuous mode.

If you are interested in Linux System Administration, we have a complete section dedicated to it on the website, so make sure to check it out!

If you are working on a small to medium entreprise network, you probably have dozens of drives and printers that need to be shared.

Besides the NFS protocol, there are plenty of other network protocols that can be used in order to share resources over a network.

The CIFS, short for Common Internet File System, is a network filesystem protocol used to share resources among multiple hosts, sharing the same operating system or not.

The CIFS, also known as the SMB protocol, is implemented by one popular tool : the Samba server.

Started in 1991, Samba was developed in the early days in order to ease the interoperability of Unix and Windows based systems.

In this tutorial, we are going to focus on the Samba installation and configuration for your network.

Prerequisites

In order to install new packages on your system, you will need to be a user with elevated permissions.

To check if you are already a sudo user, you can run the “groups” command and check if “sudo” belongs to the list.

$ groups

user sudo netdev cdrom

If you don’t belong to the sudo group, you can check one of our tutorials in order to gain sudo privileges for Debian instances.

Now that you have sudo privileges, let’s jump right into the Samba server installation.

• Syslog: The Complete System Administrator Guide
• Tcpdump Command in Linux
• Complete Node Exporter Mastery with Prometheus | Monitoring Linux Host Metrics WITH THE NODE EXPORTER

Installing Samba on Debian

Before installing Samba, you will need to make sure that your packages are up-to-date with the Debian repositories.

$ sudo apt-get update

Now that your system is up-to-date, you can run the “apt-get install” command on the “samba” package.

$ sudo apt-get install samba

When installing Samba, you will be presented with the following screen.

In short, this window is used in order to configure retrieval of NetBIOS name servers over your network.

Nowadays, your entreprise network is most likely using DNS name servers in order to store static information about hostnames over your network.

As a consequence, you are most likely not using a WINS server, so you can select the “No” option.

When resuming the installation, APT will unpack and install the packages needed for Samba.

Additionnally, a “sambashare” group will be created.

After the installation, you can check the version used on your system by running the “samba” command with the “-v” option.

$ samba -V

You can also verify that the Samba server is running by checking the status of the Samba SMB Daemon with systemctl.

$ systemctl status smbd

Great, Samba is now correctly installed on your Debian server!

Opening Samba Ports on your firewall

This section only applies if you are using UFW or FirewallD on your server.

In order for Samba to be reachable from Windows and Linux hosts, you have to make sure that ports 139 and 445 are open on your firewall.

On Debian and Ubuntu, you are probably using the UFW firewall.

In order to open ports on your UFW firewall, you have to use the “allow” command on ports 139 and 445.

$ sudo ufw allow 139
$ sudo ufw allow 445

$ sufo ufw status

If you are working on a CentOS or a RHEL server, you will have to use the “firewall-cmd” in order to open ports on your computer.

$ sudo firewall-cmd --permanent --add-port=139/tcp
success
$ sudo firewall-cmd --permanent --add-port=445/tcp
success
$ sudo firewall-cmd --reload
success

Configuring Samba on Debian

Now that your Samba is correctly installed, it is time to configure it in order to configure it in order to be able to export some shares.

Note : Samba can also be configured in order to act as a domain controller (like Active Directory) but this will be explained in another tutorial.

By default, the Samba configuration files are available in the “/etc/samba” folder.

By default, the Samba folder contains the following entries :

• gdbcommands : a file containing a set of entries for the GDB debugger (won’t be used at all here);
• smb.conf : the main Samba configuration file;
• tls : a directory used in order to store TLS and SSL information about your Samba server.

For this section, we are going to focus on the content of the smb.conf file.

The Samba configuration file is composed of different sections :

• global : as its name indicates, it is used in order to define Samba global parameters such as the workgroup (if you are using Windows), the log location, as well as PAM password synchronization if any;
• shares definitions : in this section, you will list the different shares exported by the Samba server.

Defining the Windows workgroup

If you plan on including the Samba server into a Windows workgroup, you will need to determine the workgroup your computers belong to.

If you are working on a Unix-only network, you can skip this section and jump right into share definition.

Note : if you are using a domain controller, those settings do not apply to you.

In order to find your current workgroup, head over to the Windows Start Menu, and search for “Show which workgroup this computer is on”.

Select the option provided by the search utility and you should be able to find your workgroup in the next window.

In this case, the workgroup name is simply “WORKGROUP“.

However, you will have to make sure that this name is reflected in the Samba configuration file.

Now that your workgroup is properly configured, let’s start by defining simple share definitions for your Samba server.

Defining Samba share definitions

On Samba, a share is defined by specifying the following fields :

• Share name : the name of the share as well as the future address for your share (the share name is to be specified into brackets);
• Share properties : the path to your share, if it is public, if it can be browsed, if you can read files or create files and so on.

In order to start simply, let’s create a Samba share that will be publicly available to all machines without authentication.

Note : it is recommended to setup Samba authentication if you are exporting shares containing sensitive or personal information.

Creating a public Samba share

First of all, you will need to decide on the folder to be exported on your system, for this tutorial we are going to choose “/example”.

In order for users to be able to write files to the share, they will need to have permissions on the share.

However, we are not going to set full permissions to all users on the folder, we are going to create a system account (that has write permissions) and we are going to force user to use this account when logging to Samba.

In order to create a system account, use the “useradd” command with the “-r” option for system accounts.

$ sudo useradd -rs /bin/false samba-public

$ sudo chown samba-public /example

$ sudo chmod u+rwx /example

In order to create a public Samba share, head over to the bottom of your Samba configuration file and add the following section.

$ nano /etc/samba/smb.conf

[public]
   path = /example
   available = yes
   browsable = yes
   public = yes
   writable = yes
   force user = samba-public

Here is an explanation of all the properties specified in this Samba share definition :

• path : pretty self-explanatory, the path on your filesystem to be exported with Samba;
• available : meaning that the share will be exported (you can choose to have shares defined but not exported);
• browsable : meaning that the share will be public in network views (such as the Windows Network view for example);
• public : synonym for “guest ok”, this parameter means that everyone can export this share;
• writable : meaning that all users are able to create files on the share.
• force user : when logging, users will take the identify of the “samba-public” account.

Before restarting your smbd service, you can use the “testparm” in order to check that your configuration is syntactically correct.

$ testparm

As you can see, no syntax errors were raised during the configuration verification, so we should be good to go.

Now that your share definition is created, you can restart your smbd service in order for the changes to be applied.

$ sudo systemctl restart smbd

$ sudo systemctl status smbd

Your share should now be accessible : in order to verify it, you can install the “samba-client” package and list the shares exported on your local machine.

$ sudo apt-get install smbclient

$ smbclient -L localhost

Note : you will be asked to provide a password for your workgroup. In most cases, you have no password for your workgroup, you can simply press Enter.

Connecting to Samba from Linux

In order to be able to mount CIFS filesystems, you have to install CIFS utilities on your system.

$ sudo apt-get install cifs-utils

Now that CIFS utilities are installed, you will be able to mount your filesystem using the mount command.

$ sudo mount -t cifs //<server_ip>/<share_name> <mountpoint>

Using our previous example, our exported share was named “public” and it was available on the 192.168.178.35 IP address.

Note : you can follow this tutorial if you are not sure how you can find your IP address on Linux.

If we were to mount the filesystem on the “/mnt” mountpoint, this would give

$ sudo mount -t cifs //192.168.178.35/public /mnt -o uid=devconnected

Password for root@//192.168.178.35/public : <no_password>

Now that your drive is mounted, you can access it like any other filesystem and start creating files on it.

Congratulations, you successfully mounted a CIFS drive on Linux!

Connecting to Samba from Windows

If you are using a Windows host, it will be even easier for you to connect to a Samba share.

In the Windows Search menu, look for the “Run” application.

In the Run windows, connect to the Samba share using the same set of information than the Linux setup.

Be careful : on Windows, you have to use backslashes instead of slashes.

When you are done, simply click on “Ok” in order to navigate your share!

Awesome, you successfully browsed your Samba on Windows!

Securing Samba shares

In the previous sections, we have created a public share.

However, in most cases, you may want to build secure share that are accessible only by a restricted number of users on your network.

By default, Samba authentication is separated from Unix authentication : this statement means that you will have to create separate Samba credentials for your users.

Note : you may choose to have Samba built as an AD/DC but this would be a completely different tutorial.

In order to create a new Samba, you need to use the “smbpasswd” command and specify the name of the user to be created.

$ smbpasswd <user>

Note : the user you are trying to create with Samba needs to have a Unix account already configured on the system.

Now that your user is created, you can edit your Samba configuration file in order to make your share secure.

$ nano /etc/samba/smb.conf

[private]
   path = /private
   available = yes
   browsable = yes
   public = no
   writable = yes
   valid users = <user>

Most of the options were already described in the previous section, except for the “valid users” one which, as its name specifies, authorizes the Samba access to a restricted list of users.

Again, you can test your Samba configuration with the “testparm” command and restart your Samba service if everything is okay.

$ testparm

$ sudo systemctl restart smbd

$ sudo systemctl status smbd

Now that your drive is secured, it is time for you to start accessing it from your remote operating systems.

Connecting to secure Samba using Windows

On Windows, you will have to use the same procedure than the previous step : execute the “Run” application and type the address of your share drive.

When clicking on “Ok”, you will be presented with a box asking for your credentials : you have to use the credentials you defined in the previous section with smbpasswd.

If you provided the correct password, you should be redirected to your network drive, congratulations!

Connecting to secure Samba using Linux

In order to connect to a secure Samba share using Linux, you have to use the “mount” command and provide the address of the share as well as the mount point to be used.

$ sudo mount -t cifs //<share_ip>/<share_name> <mount_point> -o username=<user>

Using the example of our “private” share on the 192.168.178.35 IP address, this would result in the following command :

$ sudo mount -t cifs //192.168.178.35/private /mnt -o username=user

Password for user@//192.168.178.35/private: <provide_password>

That’s it!

Your drive should now be correctly mounted.

You can verify that it was correctly mounted with the “findmnt” command that lists mounted filesystems.

$ findmnt /mnt

Congratulations, you successfully mounted a secure Samba share on your server!

Conclusion

In this tutorial, you learnt how you can easily install and configure a Samba server in order to share your drives.

You also learnt that you can tweak Samba share options in order to make your shares secure, whether you are using Windows or Linux.

Samba is an important tool working on the interoperability of operating systems : if you are interested in the Samba project, you should definitely check their website.

They are also providing a free alternative to Active Directory where Samba can be configured to act as a domain controller.

If you are interested in Linux System Administration, we have a complete section dedicated to it on the website, so make sure to check it out!

As a Linux system administrator, inspecting log files is one of the most common tasks that you may have to perform.

Linux logs are crucial : they store important information about some errors that may happen on your system.

They might also store information about who’s trying to access your system, what a specific service is doing, or about a system crash that happened earlier.

As a consequence, knowing how to locate, manipulate and parse log files is definitely a skill that you have to master.

In this tutorial, we are going to unveil everything that there is to know about Linux logging.

You will be presented with the way logging is architectured on Linux systems and how different virtual devices and processes interact together to log entries.

We are going to dig deeper into the Syslog protocol and how it transitioned from syslogd (on old systems) to journalctl powered by systemd on recent systems.

Linux Logging Types

When dealing with Linux logging, there are a few basics that you need to understand before typing any commands in the terminal.

On Linux, you have two types of logging mechanisms :

• Kernel logging: related to errors, warning or information entries that your kernel may write;
• User logging: linked to the user space, those log entries are related to processes or services that may run on the host machine.

By splitting logging into two categories, we are essentially unveiling that memory itself is divided into two categories on Linux : user space and kernel space.

Kernel Logging

Let’s start first with logging associated with the kernel space also known as the Kernel logging.

On the kernel space, logging is done via the Kernel Ring Buffer.

• Syslog: The Complete System Administrator Guide
• The Definitive Guide to Centralized Logging with Syslog on Linux
• Docker Logs Complete Guide | Definition of Docker Logs, Logging Strategies & Best Practices

The kernel ring buffer is a circular buffer that is the first datastructure storing log messages when the system boots up.

When you are starting your Linux machine, if log messages are displayed on the screen, those messages are stored in the kernel ring buffer.

The Kernel logging is started before user logging (managed by the syslog daemon or by rsyslog on recent distributions).

The kernel ring buffer, pretty much like any other log files on your system can be inspected.

In order to open Kernel-related logs on your system, you have to use the “dmesg” command.

Note : you need to execute this command as root or to have privileged rights in order to inspect the kernel ring buffer.

$ dmesg

As you can see, from the system boot until the time when you executed the command, the kernel keeps track of all the actions, warnings or errors that may happen in the kernel space.

If your system has trouble detecting or mounting a disk, this is probably where you want to inspect the errors.

As you can see, the dmesg command is a pretty nice interface in order to see kernel logs, but how is the dmesg command printing those results back to you?

In order to unveil the different mechanisms used, let’s see which processes and devices take care of Kernel logging.

Kernel Logging internals

As you probably heard it before, on Linux, everything is a file.

If everything is a file, it also means that devices are files.

On Linux, the kernel ring buffer is materialized by a character device file in the /dev directory and it is named kmsg.

$ ls -l /dev/ | grep kmsg

If we were to depict the relationship between the kmsg device and the kernel ring buffer, this is how we would represent it.

As you can see, the kmsg device is an abstraction used in order to read and write to the kernel ring buffer.

You can essentially see it as an entrypoint for user space processes in order to write to the kernel ring buffer.

However, the diagram shown above is incomplete as one special file is used by the kernel in order to dump the kernel log information to a file.

If we were to summarize it, we would essentially state that the kmsg virtual device acts as an entrypoint for the kernel ring buffer while the output of this process (the log lines) are printed to the /proc/kmsg file.

This file can be parsed by only one single process which is most of the time the logging utility used on the user space. On some distributions, it can be syslogd, but on more recent distributions it is integrated with rsyslog.

The rsyslog utility has a set of embedded modules that will redirect kernel logs to dedicated files on the file system.

Historically, kernel logs were retrieved by the klogd daemon on previous systems but it has been replaced by rsyslog on most distributions.

On one hand, you have logging utilities reading from the ring buffer but you also have user space programs writing to the ring buffer : systemd (with the famous systemd-journal) on recent distributions for example.

Now that you know more about Kernel logging, let’s see how logging is done on the user space.

User side logging with Syslog

Logging on the userspace is quite different from logging on the kernel space.

On the user side, logging is based on the Syslog protocol.

Syslog is used as a standard to produce, forward and collect logs produced on a Linux instance.

Syslog defines severity levels as well as facility levels helping users having a greater understanding of logs produced on their computers.

Logs can later on be analyzed and visualized on servers referred as Syslog servers.

In short, the Syslog protocol is a protocol used to define the log messages are formatted, sent and received on Unix systems.

Syslog is known for defining the syslog format that defines the format that needs to be used by applications in order to send logs.

This format is well-known for defining two important terms : facilities and priorities.

Syslog Facilities Explained

In short, a facility level is used to determine the program or part of the system that produced the logs.

On your Linux system, many different utilities and programs are sending logs. In order to determine which process sent the log in the first place, Syslog defines numbers, facility numbers, that are used by programs to send Syslog logs.

There are more than 23 different Syslog facilities that are described in the table below.

Most of those facilities are reserved to system processes (such as the mail server if you have one or the cron utility). Some of them (from the facility number 16 to 23) can be used by custom Syslog client or user programs to send logs.

Syslog Priorities Explained

Syslog severity levels are used to how severe a log event is and they range from debug, informational messages to emergency levels.

Similarly to Syslog facility levels, severity levels are divided into numerical categories ranging from 0 to 7, 0 being the most critical emergency level.

Again, here is a table for all the priority levels available with Syslog.

Here are the syslog severity levels described in a table:

Syslog Architecture

Syslog also defines a couple of technical terms that are used in order to build the architecture of logging systems :

• Originator : also known as a “Syslog client”, an originator is responsible for sending the Syslog formatted message over the network or to the correct application;
• Relay : a relay is used in order to forward messages over the network. A relay can transform the messages in order to enrich it for example (famous examples include Logstash or fluentd);
• Collector : also known as “Syslog servers”, collectors are used in order to store, visualize and retrieve logs from multiple applications. The collector can write logs to a wide variety of different outputs : local files, databases or caches.

As you can see, the Syslog protocol follows the client-server architecture we have seen in previous tutorials.

One Syslog client creates messages and sends it to optional local or distant relays that can be further transferred to Syslog servers.

Now that you know how the Syslog protocol is architectured, what about our own Linux system?

Is it following this architecture?

Linux Local Logging Architecture

Logging on a local Linux system follows the exact principles we have described before.

Without further ado, here is the way logging is architectured on a Linux system (on recent distributions)

Following the originator-relay-collector architecture described before, in the case of a local Linux system :

• Originators are client applications that may embed syslog or journald libraries in order to send logs;
• No relays are implemented by default locally;
• Collectors are rsyslog and the journald daemon listening on predefined sockets for incoming logs.

So where are logs stored after being received by the collectors?

Linux Log File Location

On your Linux system, logs are stored in the /var/log directory.

Logs in the /var/log directory are split into the Syslog facilities that we saw earlier followed by the log suffix : auth.log, daemon.log, kern.log or dpkg.log.

If you inspected the auth.log file, you would be presented with logs related to authentication and authorization on your Linux system.

Similarly, the cron.log file displays information related to the cron service on your system.

However, as you can see from the diagram above, there is a coexistence of two different logging systems on your Linux server : rsyslog and systemd-journal.

Rsyslog and systemd-journal coexistence

Historically, a daemon was responsible for gathering logs from your applications on Linux.

On many old distributions, this task was assigned to a daemon called syslogd but it was replaced in recent distributions by the rsyslog daemon.

When systemd replaced the existing init process on recent distributions, it came with its own way of retrieving and storing logs : systemd-journal.

Now, the two systems are coexisting but their coexistence was thought to be backwards compatible with the ways logs used to be architectured in the past.

The main difference between rsyslog and systemd-journal is that rsyslog will persist logs into the log files available at /var/log while journald will not persist data unless configured to do it.

Journal Log Files Location

As you understood it from the last section, the systemd-journal utility also keeps track of logging activities on your system.

Some applications that are configured as services (an Apache HTTP Server for example) may talk directly to the systemd journal.

The systemd journal stores logs in a centralized way is the /run/log/journal directory.

The log files are stored as binary files by systemd, so you won’t be able to inspect the files using the usual cat or less commands.

Instead, you want to use the “journalctl” command in order to inspect log files created by systemd-journal.

$ journalctl

There are many different options that you can use with journalctl, but most of the time you want to stick with the “-r” and “-u” option.

In order to see the latest journal entries, use “journalctl” with the “-r” option.

$ journalctl -r

If you want to see logs related to a specific service, use the “-u” option and specify the name of the service.

$ journalctl -u <service>

For example, in order to see logs related to the SSH service, you would run the following command

$ journalctl -u ssh

Now that you have seen how you can read configuration files, let’s see how you can easily configure your logging utilities.

Linux Logging Configuration

As you probably understood from the previous sections, Linux logging is based on two important components : rsyslog and systemd-journal.

Each one of those utilities has its own configuration file and we are going to see in the following chapters how they can be configured.

Systemd journal configuration

The configuration files for the systemd journal are located in the /etc/systemd directory.

$ sudo vi /etc/systemd/journald.conf

The file named “journald.conf” is used in order to configure the journal daemon on recent distributions.

One of the most important options in the journal configuration is the “Storage” parameter.

As specific before, the journal files are not persisted on your system and they will be lost on the next restart.

To make your journal logs persistent, make sure to modify this parameter to “persistent” and to restart your systemd journal daemon.

To restart the journal daemon, use the “systemctl” command with the “restart” option and specify the name of the service.

$ sudo systemctl restart systemd-journald

As a consequence, journal logs will be stored into the /var/log/journal directory next to the rsyslog log files.

$ ls -l /var/log/journal

If you are curious about the systemd-journal configuration, make sure to read the documentation provided by FreeDesktop.

Rsyslog configuration

On the other hand, the rsyslog service can be configured via the /etc/rsyslog.conf configuration file.

$ sudo vi /etc/rsyslog.conf

As specified before, rsyslog is essentially a Syslog collector but the main concept that you have to understand is that Rsyslog works with modules.

Its modular architecture provides plugins such as native ways to transfer logs to a file, a shell, a database or sockets.

Working with rsyslog, there are two main sections that are worth your attention : modules and rules.

Rsyslog Modules

By default, two modules are enabled on your system : imuxsock (listening on the syslog socket) and imjournal (essentially forwarding journal logs to rsyslog).

Note : the imklog (responsible for gathering Kernel logs) might be also activated.

Rsyslog Rules

The rules section of rsyslog is probably the most important one.

On rsyslog, but you can find the same principles on old distributions with systemd, the rules section defines which log should be stored to your file system depending on their facility and priority.

As an example, let’s take the following rsyslog configuration file.

The first column describes the rules applied : on the left side of the dot, you define the facility and on the right side the severity.

A wildcard symbol “*” means that it is working for all severities.

As a consequence, if you want to tweak your logging configuration in order, say for example that for example you are interested in only specific severities, this is the file you would modify.

Linux Logs Monitoring Utilities

In the previous section, we have seen how you can easily configure your logging utilities, but what utilities can you use in order to read your Linux logs easily?

The easiest way to read and monitor your Linux logs is to use the tail command with the “-f” option for follow.

$ tail -f <file>

For example, in order to read the logs written in the auth.log file, you would run the following command.

$ tail -f /var/log/auth.log

Another great way of reading Linux logs is to use graphical applications if you are running a Linux desktop environment.

The “Logs” application is a graphical application designed in order to list application and system logs that may be stored in various logs files (either in rsyslog or journald).

Linux Logging Utilities

Now that you have seen how logging can be configured on a Linux system, let’s see a couple of utilities that you can use in case you want to log messages.

Using logger

The logger utility is probably one of the simpliest log client to use.

Logger is used in order to send log messages to the system log and it can be executed using the following syntax.

$ logger <options> <message>

Let’s say for example that you want to send an emergency message from the auth facility to your rsyslog utility, you would run the following command.

$ logger -p auth.emerg "Somebody tried to connect to the system"

Now if you were to inspect the /var/log/auth.log file, you would be able to find the message you just logged to the rsyslog server.

$ tail -n 10 /var/log/auth.log | grep --color connect>

The logger is very useful when used in Bash scripts for example.

But what if you wanted to log files using the systemd-journal?

Using systemd-cat

In order to send messages to the systemd journal, you have to use the “systemd-cat” command and specify the command that you want to run.

$ systemd-cat <command> <arguments>

If you want to send the output of the “ls -l” command to the journal, you would write the following command

$ systemd-cat ls -l

It is also possible to send “plain text” logs to the journal by piping the echo command to the systemd-cat utility.

$ echo "This is a message to journald" | systemd-cat

Using wall

The wall command is not related directly to logging utilities but it can be quite useful for Linux system administration.

The wall command is used in order to send messages to all logged-in users.

$ wall -n <message>

If you were for example to write a message to all logged-in users to notify them about the next server reboot, you would run the following command.

$ wall -n "Server reboot in five minutes, close all important applications"

Conclusion

In this tutorial, you learnt more about Linux logging : how it is architectured and how different logging components (namely rsyslog and journald) interact together.

You learnt more about the Syslog protocol and how collectors can be configured in order to log specific events on your system.

Linux logging is a wide topic and there are many more topics for you to explore on the subject.

Did you know that you can build centralized logging systems in order to monitor logs on multiple machines?

If you are interested about centralized logging, make sure to read our guide!

Also, if you are passionate about Linux system administration, we have a complete section dedicated to it on the website, so make sure to check it out!