Linux Crash Course - Understanding Logging

foreign [Music] hello again everyone and welcome back to learn Linux TV in today's video we're going to talk about logging logging is really important because when we manage Linux servers we want to know what's going on at any given time what's happening what's connecting to our servers who's using our servers things like that and using logs we can find out all kinds of information about our server even if we're just troubleshooting Hardware or something like that there's a log file for just about every use case so what I'm going to do in this video is go over the basics of logging I'm going to show you guys some of the essential log files and I'll also throw in the journal CTL command or at least the basics of the journal CTL command for safe measure and it's going to be a lot of fun now before we get into the topic at hand I need to take a moment to mention the sponsor for today's video lenode if you haven't already heard of lenode well they're a Linux Focus Cloud Server provider and with their platform you can spin up your very own Linux server in mere minutes and considering that there's over 40 videos in this series as of recording time with many more coming the note is a great service that you could use for spinning up test servers and you could use those test servers to go along with the various tutorials that are available on this channel and by using the URL that you see on the screen right now that'll get you one hundred dollars in free credit towards your new account and that credit is good for up to 60 days and by using that URL you're actually supporting learn Linux TV and I'd greatly appreciate that and their platform is great for more than just spinning up test servers the note is the real deal when it comes to providing cloud computing resources you can literally run your entire business on the Node or you could use it to do something fun like spitting up a Minecraft server so you and your friends can build a World online together the only limit is your imagination so definitely check them out and thank you so much to lenode for sponsoring this video along with many others on this channel I really appreciate it anyway I'm very excited to get started so let's go ahead and dive in and take a look at the basics of logging in Linux [Music] so here on the screen right now what you're seeing is a terminal that's actually connected to a fedora instance I'm actually going to show you the default log files on another distribution as well and the reason for that is because different distributions might name the log files differently so here I'm actually using Fedora 36 and later in the video I'll show you guys some of the log files on Ubuntu as well but since we're here on a fedora instance let's go ahead and check out the file names for the log files as they exist for this distribution now it's quite common that log files will be found in slash bar log so let's start there if I list the storage you'll see that we have a bunch of log files right here inside this directory a lot of them will actually end in DOT log like you see right here but not all of them do for example we have last log right here that doesn't have a file extension at all and this one actually does have log at the end of the file name but no period so it is common to see a DOT log file extension but I don't want you guys to be under the impression that there's consistency here when it comes to how these files were named so if you're simply looking for every file that ends in DOT log then you're not actually seeing all of the files that might be here so let me clear the screen and then do a normal LS without a long listing because that helps us fit everything onto one screen like you're seeing here and we'll look at some of these logs now I'm not going to show you every single log file that you might have there's no shortage of log files and it'd be a super long video if I went over everything you might have here but I'll definitely cover the most common now I'm not going to go over these in any particular order so randomly I'm going to pick the boot.log as the place to start here and as you could probably guess from the name the boot.log file actually pertains to the boot process so what I'm going to do is try to cut it out I might not have permission to do this but let's just see and I don't and it's going to be very common that you might not have access as a normal user to a log file but if you use the sudo command or if you're logged in as root then you should have no problem viewing the log files so let's try that again boot.log now this could be very useful if you're troubleshooting the boot process perhaps you have a physical server and you have a monitor attached to it or if it's a VM server you might have a KVM or something but anyway you're watching the boot process you're seeing all of these messages fly by the screen and you catch a glimpse of the word error within the output but the problem is that the boot process flies by so quickly that you might not be able to read the message before it goes away so you can think of the boot.log file as a log file you can check when you want to go back and read some of the messages that might have appeared during the boot process now as an aside another distributions you might not have a file named boot.log I'm on a fedora system so your results might vary depending on your distribution if you don't have a boot.log file you don't have to worry about it just understand that if you do have a boot.log file well now you know what it's for and if I scroll through the output here we can see all of the messages right here so it looks like in my case everything is good I have okay straight down the board here so at first glance I'm not seeing anything that's of potential concern right here it looks like the boot process at least in my case has been successful continuing we have the dnf.log file which is another log file that's specific to Fedora but the dnf.log file what that allows us to do is view a history of the packages that were recently installed on the server so for example we might have an error message and that error message might have something to do with packaging packages that are installed maybe something is missing like a shared library or something like that or perhaps a package was installed that's conflicting with packages that were already installed so what we can do is take a look at this log file and then see which packages were recently installed and for this log file I shouldn't need sudo to view it so let's just use cat and then dnf.log and there it is so we can see that the RPM Fusion repository here on Fedora was downloading some information so that's fine and there's a lot of information here as you can see so not just package installations or removals there's other pieces of info here as well but there's no shortage of information now most of this right here is just the repositories being refreshed and things like that but right here we can actually see where I downloaded The Gnome console application actually installed this about six or seven days ago or so but as you can see right here I've downloaded a package and the log file contains an entry right here where I went to install that package so again if that's something that you want to find out you want to find out what's been installed recently then checking out the dnf.log file at least on systems that use the dnf package manager that's going to be a great way to find out now Another Log file that I would like to point you guys to is the wtemp log file so let's go ahead and check out the contents of that file and it's just WTMP in the varlog directory and this is strange we're not able to read it there's all these funny characters here and yeah there's some legible information but at least for me I can't understand what exactly is going on here because I see well a bunch of weird characters what's going on well actually the WTMP log file is known as a binary log and we could gather that it's not a simple text file on account of the fact that we didn't get simple text when we went to inspect the contents of the file but to view a binary log if you see a situation like this where you can't read it then that generally means that there's some other command that you have to use to view that log file properly and in our case it's actually the last command that's going to be the command that we will use to view the contents of that file so I'll enter last just like that and press enter and now we can actually read the information so up here we have the binary version but then when I used the last command like I've used right here we actually see some contents and the whole purpose of the WTMP file or wtemp file depending on how you want to pronounce that is it gives us a detail of all the login and logout events so if we wanted to I don't know audit the users that are logging into our server then the wtemp log file will be the one that we want to inspect and we'll use the last command in order to do that now another file that I would like to let you guys know about is the B temp file btmp and of course we could try to cat out the contents of that file I wouldn't recommend it but we can certainly do it anyway and of course permission is denied because that particular log file needs root access and I forgot about that so I'll just type sudo cat and then B temp and well I have no idea what this is so basically we have another binary log and if we have a binary log like I mentioned we'll need to use some sort of command in order to get the information from that log file and to do that what we'll type is again sudo because in this case we will need that then last B so previously we used the last command and now we're using last B and B I believe stands for bad because the B temp file is specific to bad login attempts so for example if you're only interested in the bad login attempts if somebody's trying to break into your server or something like that then you're probably not going to care about the successful login attempts so the last B command or the B temp log file is going to contain bad login attempts let's give it the options ADF and in this case f is capitalized now before I actually press enter what I want to do is let you guys know what these individual options mean and starting with the dash a option what that's going to do is show the hostname in the last column the Dash D option there in the middle that's going to attempt to match DNS names to IP addresses which is probably something that would be useful if we have that available and the dash capital F option what that's going to do is give us the full times for the times that are shown from this command so I'll press enter and right here we have an attempt where I try to log in apparently but this particular instance is not publicly available so we shouldn't really see anything here at least not all that much so only having one entry here is not all that surprising to me but anyway if you have a server that is publicly available or even if it's not and you just want to know you know who's trying to get into your server then the command that I just gave you sudo last b-ad capital F that's the command that you can use and that information is stored in the B temp log file which is a binary log so we use the last B command to view that log file now what I'm going to do at this point is actually wipe this computer and install Ubuntu on it and reason being this is my footage PC and there's some recordings that I need to get done that actually use Ubuntu so what I'll do is I'll just wipe this machine install Ubuntu and then I'll be right back [Music] so here I am an Ubuntu this is the exact same machine as earlier in the video except like I mentioned I went ahead and just wiped out Fedora and installed Ubuntu and that's just how it goes when it comes to making YouTube videos I find myself installing various distributions all day long and you know what I wouldn't have it any other way but as you can see here I am on Ubuntu 2204 so let's go ahead and take a look at the VAR log directory and we should immediately see how Ubuntu differs from distributions like fedora and although we do have a few log files here that are the same as in Fedora most of them are actually different now when it comes to Fedora the file names for the log files on that distribution should be relatively similar when compared to Centos Red Hat Alma Linux Rocky Linux or basically any distribution that is based on the red hat family and then here on Ubuntu the log file names that you see right here other distributions like Debian for example are going to have similar names for their log files so it's not like you have to learn a completely different set of log files for every distribution there's going to be a lot of overlap when it comes to a distribution family and Ubuntu being heavily related to Debian then of course on Debian and distributions based on Debian then a lot of what I'm going to mention is going to carry over to that as well now first of all what I want to do is check out the off.log file and I will need root for that or at least sudo so I'll type sudo and then I'll just count out the contents to keep it simple and it's varlogoff.log and the off log actually short for authorization log and on a Debian or Ubuntu or an equivalent server then what you're going to see in this log file are login attempts and if I scroll through here we could probably see I'm assuming a situation where I fat finger the password normally I edit that out of the video so you don't know that I'm messing up the password maybe I shouldn't have given that away but anyway login attempts are stored in the authorization log or off of that log for short and another thing that the off log is actually useful for is troubleshooting now what I'm going to do is do a tail follow on that log file which is a very very very important trick to learn because when you have a text file not a binary log file but a log file that's a text file you can follow the output of that log file and see the output show up on your screen as soon as anything is actually entered into that log file and what I'll do is type tail Dash F and I will need sudo and you'll see immediately what this does if you didn't already know and then I'll type the full path to the authorization log and the tail command as you might already know that gives you the last portion of a particular file so that way you don't have a flood of text if there's thousands upon thousands of lines if you only care about what's at the end of the file then the tail command by itself is useful for that but as soon as we add the dash F option for follow then you'll notice I can't enter any commands here I have a blinking cursor and what this means is that I'm in follow mode and in this mode anytime something new is written to this file then you're going to see it right here now what I'm going to do is show you an example of follow and why it's so useful so I'm currently following the log right now and on another computer what I'm going to do is attempt to SSH into this particular computer so I'll do that right now so what I've done from a different computer is I've attempted to log into this computer via SSH and on purpose I typed the incorrect password so for example if you had a user and you are managing a Linux server and that user comes to you and lets you know that they can't actually connect to the server via SSH then a very common troubleshooting technique in that situation is to have your user try again while you're in the process of following the log file the off log and you can see the actual errors or the reason why they're not able to log in in this case it's a simple password failure which is not all that exciting or even all that uncommon but I wanted to show you guys an example of why you might want to follow the log file and as you can see right here I was able to follow the authorization log and see in almost real time what exactly is happening on the server if I saw a bunch of attempts here in this particular instance was publicly available then that might be a cause for alarm that might mean that somebody's trying to get into my server but it's not some outside attacker this time around it's just me with my fat fingers and my inability to type a password but anyway back to the topic at hand which of course is logging what we've just done is we've taken a look at the authorization log and that was in the varlog directory and these are the log files that exist at least on Ubuntu and Debian systems and the authorization log is a very important log file so if you're on a Debian or Ubuntu system then it's really important to understand and keep in mind that that particular log file is the one that you should check if you have I don't know some sort of authorization related thing that you're troubleshooting because you might find your information within that log file now there's another log file that's very important to keep in mind and that is the system log and we call it syslog for short and depending on how your distribution is configured you may or may not have access to this particular log file the one I want to show you which is the system log so I'll just cut out the contents of the syslog and if it doesn't work for you you could just simply prefix the command with sudo and that should enable you to inspect the file and as we scroll through the output here you should be able to see what exactly this log file is for which is well system events and that makes sense it is the syslog so if you're troubleshooting something like hardware issues you might want to take a look at this file and sometimes if you're troubleshooting something like USB maybe a flash drive and I don't know maybe it's not detected then you can actually tail this log file while you insert or remove that particular device and if your computer or server is recognizing that device and you should see something in here that will show you that it's been found now if you don't see that you might have something wrong with your USB ports but anyway the main point right here is that the assist log is for well system events that's why it's called the syslog and it's right here in the varlog directory now in the previous section what I did was I showed you the dnf log and that log file is going to be very common for systems that have the dnf package manager distributions like Fedora for example but here on Ubuntu I have the APT package manager so I'm not going to have a dnf log file because there's no dnf but what I do have is an apt directory is closer to the upper left of the output there and if I go inside that directory you can see that I have a few log files right here as well if I add the long listing we can see that the permissions here are such that anybody can view these files so I should be able to cut out the history.log file for example without sudo or anything like that and sure enough I was able to do that and like I mentioned earlier I just set up this installation I was running Fedora on this particular machine now I'm running Ubuntu and what you're seeing here in the log file are some of the packages that I went ahead and installed off camera things that I generally want to be available like gnome tweaks for example I wanted to add that I did some package cleanup with the APT Auto remove command and I have an entire video that's all about apt if you want to check that out but another thing that I did right here is I performed a full distribution upgrade which in terms of Ubuntu and related distributions means to install every available update and as you can see from a fresh installed Ubuntu 2204 I had quite a few packages here for installation and the purpose of this log file right here is essentially the same as the dnf log as we've checked out in the previous section if you have a situation where I don't know maybe something related to packages isn't working quite right then you can check this log file see if anything was changed recently or installed removed updated things like that for example if you're having updates with one of the packages here maybe LibreOffice is giving us trouble I don't know why I decided to use that as an example but I did see that a Libre office related package was indeed part of the output here so if I was actually having problems with that or any of these other apps that you see here within the output then that might give me some kind of a clue that an update might have came along that is having some sort of a problem and if that's the case then well I can act accordingly which might be to roll it back or to file a bug report or something like that but anyway the takeaway here is that if you want to find out what types of shenanigans are going on with your Linux packaging then you could check the dnf log on Red Hat Family servers or the appropriate file within the APT directory inside slash fire slash log for Debian and Ubuntu and you'll be able to get that information so let's go back one directory and see what else we have here now I've already gone over the W temp and B temp log files so we really shouldn't need to see that one again and of course I've gone over the off log so we already know what that is but let's check out the D message log file and the D message log file and again that was DM ESG that log file is in some way similar to the syslog file the system log shows you system related events and D message shows you the same thing also system related events it shows it a bit differently so you have a different format for time which we're not going to get into right now but you'll see different information here and you might even see the same information about some things as in the syslog file with a difference being that there might be more information here in the D message log file but if you scroll through you might be able to see more information especially if you are troubleshooting Hardware because this is actually a kernel log file and that could be very important when it comes to troubleshooting Hardware because you need to understand how the Linux kernel has actually seen something that you've attached so for example right here you can see that I have a Logitech USB mouse so we can see that it recognized that and it attached it right here so we know where exactly this is attached to on the system so we can keep track of that if we're having issues with our Logitech mouse then we can probably use this information to help us troubleshoot that if nothing else if it doesn't show anything here at all when it comes to USB devices but we definitely did plug something in we might have disabled USB ports maybe some sort of driver issue but all things considered if you want to check out Hardware related events the D message log file is one way to do that and in addition to that there's actually a dedicated command for the D message log file and this log file is not a binary log I mentioned earlier that you might need a special command for binary logs if you run into one but we can actually execute the D message command like you see right here and in our case it actually gives me permission denied which is kind of weird considering that I can actually view the log file but what I'll do is just run sudo exclamation mark exclamation mark which just runs the most recent command but puts sudo in front of it might save us a little bit of typing even though D message isn't really all that long of a file name anyway I pressed enter here and you can see we have some colorization which is really nice we have the same information though so for troubleshooting any hardware then the D message log file would be a fantastic way of doing that so I'm going to go back to the home directory here there's another example of logging that I want to make sure that I go over and that's the journal CTL command the journal CTL command is specific to systemd and distributions that use systemd but quite a few distributions do Fedora Ubuntu Debian Arch off the top of my head and many others they all use systemd but what exactly is systemd well system D is actually an init system it's beyond the scope of this video to give you a full overview of systemd it's definitely something that we should go over if we haven't already done so but Journal CTL is also a command that comes along for the ride on a system that uses system D and what the journal CTL file allows us to do is inspect actual units or services on the system and view the log files that pertain to those particular services and to use the journal CTL command what you do is you type Dash U and then the name of a unit you might think of a unit as a service that's running in the background a demon if you will there's different names for the same thing but what Journal CTL is going to do is allow us to view output pertaining to a specific service for example I'm running SSH on this computer so I'll press enter and now I'm seeing log entries that are specific to SSH now system D is probably more famous for a systemctl or system control command which allows us to do something like start and then a unit name which could be Apache or something like that and this command allows us to start stop enable services and there's another video on my channel that goes over this in more detail but the reason why I bring up system CTL is because if you can use system CTL to start a unit for example let's just say you have a web server and on that web server maybe you've installed Apache I haven't installed Apache on this one but the point is if you've installed something and you can start it or control it with systemctl then chances are you can use Journal CTL to view the output of that unit so getting back to journal CTL you already saw in the previous example that I could run journal ctl-u and then the name of a service again anything that you can start or manage with systemd should be a prime candidate for this but another variation is I want to show you the follow mode of Journal CTL you just type Dash F along with any other options that you might have so in this case the full command is Journal CTL Dash Fu SSH which is kind of a funny set of options there it's not intentional at all it's just Dash f for follow and dash U for unit we want to follow a unit and in this case we're going to follow SSH and this is very similar to tailing the authorization log like we did earlier but the difference here is that the output is specific to SSH so I just added a bunch of spaces there and I'm going to attempt to log in I'm going to fail the password on purpose and as you can see I failed the password on purpose a few times here but I was able to get the output and follow the output of the SSH unit via Journal CTL which is another way that we could do it there's nothing wrong with using the authorization log the authorization log might have some additional information in there that might not pertain to SSH so you could argue that running the journal CTL command this one right here and following specifically SSH is one way that we can actually troubleshoot something like connecting to SSH or maybe if a user is having a problem using SSH this might be one way that we go about trying to find information about what kind of problem that person might be running into [Music] now of course we've only just scratched the surface when it comes to logging in Linux what I've covered so far in this video is definitely enough to get you started now if this video was helpful to you guys please make sure to click that like button and also subscribe because I have some awesome content coming very soon if I do say so myself and I'll see you in the next video [Music] thank you

Channel: Learn Linux TV

Views: 37,815

Keywords: Linux, gnu/linux, LearnLinuxTV, Learn Linux TV, LearnLinux.TV, Learn Linux, Linux Training, Linux Tutorials, log files, logging, linux logging, linux log files, journalctl, linux operating system, learn linux ubuntu for beginners, learn linux ubuntu, linux tutorial 2022, open source software, open source, command line basics, linux tutorial, linux command line, command line, linux for beginners, linux terminal, linux basic commands, linux essentials commands, linux server

Id: 6uP_f_z3CbM

Length: 29min 9sec (1749 seconds)

Published: Tue Oct 25 2022