In this video, you'll learn about rsyslogd.
So rsyslogd is the legacy logging service.
It has been used on Linux for a long time, and you will still find it on most Linux distributions.
There is systemd journald nowadays, but most distributions have not yet completely transitioned.
So rsyslogd is the legacy logging service.
It's based on syslogd, which is even older.
It has been used for logging in Unix and Linux since the 1980s.
In rsyslogd, facilities and priorities are used to define how logging should be happening,
and facilities define the item for which logging is happening.
The problem with rsyslogd is that there is a limited number of facilities, and that made
it difficult to add new services as new services were introduced.
Priorities define the severity levels in which case messages should be logged.
And based on these facilities and priorities, a destination is defined.
And this destination is often in a file in the slashvar slash log directory, but it can
be somewhere else as well.
That is because rsyslogd is modular, and you can use a module to log to a remote server
or to a database, and whatever the module allows you to do.
Let me show you.
So first, I want to show you that rsyslogd is still running.
Depending on your distribution, you might have to check for rsyslogd service or rsyslogd
service.
As you can see, rsyslogd is running.
In case you are wondering why, well, that is because rsyslogd has these modules, and
some people really depend on these modules to send your logs to a database or to a central
server, for instance.
And systemd journald has not been developed with centralization in mind.
Now the configuration file behind all of this is in etc rsyslog, where we have rsyslog.conf.
And once again, we see the strategy where you have the generic configuration file and
the drop-in directory where you can add your own additions.
Now in this generic configuration file, there are global directives.
And these global directives define the modules that you want to use.
Here, for instance, we can see that the module im-journal is loaded.
Im stands for input, and this makes an input module journal.
And that makes it rsyslog receives messages from the systemd journal.
Here also we see interesting options.
It's commented out, but these options are what you need to use if you want to enable
rsyslog as a centralized logging service.
So you can do that on TCP or on UDP, and the default port is 514.
And the only thing you need to do is remove the hashes to make this a log service.
But the most interesting thing is right here, the rules.
The rules define the facility, the priority, and the destination.
Let's start with this one, even if it is commented out.
The facility is kern, and the priority is everything.
And devconsole is a console where you are working at.
So what is this doing?
This makes it if the kernel is logging anything, you'll see it on your console.
Here we have another one, star dot.
Oh, that is star.
Star means all facilities.
And for all facilities, if something with a log level of info and higher has been logged,
it will be written to var log messages, which on CentOS and related is the default log file.
Also interesting is the semicolon.
Semicolon allows you to specify multiple facility priority pairs on the same line.
So mail none, authpriv none, and cron none, which means that nothing about mail or authentication
or cron will be logged.
And that is because authpriv, authentication-related messages, are written to var log secure and so on.
This is an interesting one, star dot emerge.
If you reach the highest priority, emergency, then definitely your users will notice that something is going wrong.
And what do we want to do?
We want to inform them about it.
And that is what we do by calling the OM, which is an output module, userMessage.
And the OM userMessage is sending a message to all users that are currently logged in.
I think this is enough about our Syslog, because anyways, the main logging nowadays is systemd journald.