1 00:00:00,000 --> 00:00:10,520 In this video, you'll learn about rsyslogd. 2 00:00:10,520 --> 00:00:13,120 So rsyslogd is the legacy logging service. 3 00:00:13,120 --> 00:00:19,840 It has been used on Linux for a long time, and you will still find it on most Linux distributions. 4 00:00:19,840 --> 00:00:26,360 There is systemd journald nowadays, but most distributions have not yet completely transitioned. 5 00:00:26,360 --> 00:00:29,440 So rsyslogd is the legacy logging service. 6 00:00:29,440 --> 00:00:32,360 It's based on syslogd, which is even older. 7 00:00:32,360 --> 00:00:38,439 It has been used for logging in Unix and Linux since the 1980s. 8 00:00:38,439 --> 00:00:44,080 In rsyslogd, facilities and priorities are used to define how logging should be happening, 9 00:00:44,080 --> 00:00:48,599 and facilities define the item for which logging is happening. 10 00:00:48,599 --> 00:00:53,240 The problem with rsyslogd is that there is a limited number of facilities, and that made 11 00:00:53,240 --> 00:00:59,560 it difficult to add new services as new services were introduced. 12 00:00:59,560 --> 00:01:04,680 Priorities define the severity levels in which case messages should be logged. 13 00:01:04,680 --> 00:01:09,519 And based on these facilities and priorities, a destination is defined. 14 00:01:09,519 --> 00:01:14,680 And this destination is often in a file in the slashvar slash log directory, but it can 15 00:01:14,680 --> 00:01:16,720 be somewhere else as well. 16 00:01:16,720 --> 00:01:22,800 That is because rsyslogd is modular, and you can use a module to log to a remote server 17 00:01:22,800 --> 00:01:26,680 or to a database, and whatever the module allows you to do. 18 00:01:26,680 --> 00:01:28,760 Let me show you. 19 00:01:28,760 --> 00:01:34,120 So first, I want to show you that rsyslogd is still running. 20 00:01:34,120 --> 00:01:38,879 Depending on your distribution, you might have to check for rsyslogd service or rsyslogd 21 00:01:38,879 --> 00:01:39,879 service. 22 00:01:39,879 --> 00:01:42,440 As you can see, rsyslogd is running. 23 00:01:42,440 --> 00:01:47,320 In case you are wondering why, well, that is because rsyslogd has these modules, and 24 00:01:47,320 --> 00:01:52,199 some people really depend on these modules to send your logs to a database or to a central 25 00:01:52,199 --> 00:01:53,800 server, for instance. 26 00:01:53,800 --> 00:01:59,919 And systemd journald has not been developed with centralization in mind. 27 00:01:59,919 --> 00:02:08,320 Now the configuration file behind all of this is in etc rsyslog, where we have rsyslog.conf. 28 00:02:08,320 --> 00:02:13,199 And once again, we see the strategy where you have the generic configuration file and 29 00:02:13,199 --> 00:02:17,160 the drop-in directory where you can add your own additions. 30 00:02:17,160 --> 00:02:21,139 Now in this generic configuration file, there are global directives. 31 00:02:21,139 --> 00:02:25,220 And these global directives define the modules that you want to use. 32 00:02:25,220 --> 00:02:30,020 Here, for instance, we can see that the module im-journal is loaded. 33 00:02:30,020 --> 00:02:34,740 Im stands for input, and this makes an input module journal. 34 00:02:34,740 --> 00:02:40,820 And that makes it rsyslog receives messages from the systemd journal. 35 00:02:40,820 --> 00:02:42,699 Here also we see interesting options. 36 00:02:42,699 --> 00:02:48,339 It's commented out, but these options are what you need to use if you want to enable 37 00:02:48,339 --> 00:02:51,580 rsyslog as a centralized logging service. 38 00:02:51,580 --> 00:02:57,460 So you can do that on TCP or on UDP, and the default port is 514. 39 00:02:57,460 --> 00:03:03,259 And the only thing you need to do is remove the hashes to make this a log service. 40 00:03:03,259 --> 00:03:07,100 But the most interesting thing is right here, the rules. 41 00:03:07,100 --> 00:03:12,380 The rules define the facility, the priority, and the destination. 42 00:03:12,380 --> 00:03:15,259 Let's start with this one, even if it is commented out. 43 00:03:15,259 --> 00:03:19,699 The facility is kern, and the priority is everything. 44 00:03:19,699 --> 00:03:23,100 And devconsole is a console where you are working at. 45 00:03:23,100 --> 00:03:24,419 So what is this doing? 46 00:03:24,419 --> 00:03:30,300 This makes it if the kernel is logging anything, you'll see it on your console. 47 00:03:30,300 --> 00:03:32,779 Here we have another one, star dot. 48 00:03:32,779 --> 00:03:35,020 Oh, that is star. 49 00:03:35,020 --> 00:03:36,899 Star means all facilities. 50 00:03:36,899 --> 00:03:42,259 And for all facilities, if something with a log level of info and higher has been logged, 51 00:03:42,259 --> 00:03:48,619 it will be written to var log messages, which on CentOS and related is the default log file. 52 00:03:48,619 --> 00:03:50,500 Also interesting is the semicolon. 53 00:03:50,500 --> 00:03:56,619 Semicolon allows you to specify multiple facility priority pairs on the same line. 54 00:03:56,619 --> 00:04:02,699 So mail none, authpriv none, and cron none, which means that nothing about mail or authentication 55 00:04:02,699 --> 00:04:04,539 or cron will be logged. 56 00:04:04,539 --> 00:04:12,059 And that is because authpriv, authentication-related messages, are written to var log secure and so on. 57 00:04:12,059 --> 00:04:15,500 This is an interesting one, star dot emerge. 58 00:04:15,500 --> 00:04:22,380 If you reach the highest priority, emergency, then definitely your users will notice that something is going wrong. 59 00:04:22,380 --> 00:04:23,859 And what do we want to do? 60 00:04:23,859 --> 00:04:26,220 We want to inform them about it. 61 00:04:26,220 --> 00:04:32,660 And that is what we do by calling the OM, which is an output module, userMessage. 62 00:04:32,660 --> 00:04:38,059 And the OM userMessage is sending a message to all users that are currently logged in. 63 00:04:38,059 --> 00:04:45,059 I think this is enough about our Syslog, because anyways, the main logging nowadays is systemd journald.