Linux Foundation LFCS – Domain No. 2 – Operation of running system Part 4
In this lecture we’re going to talk about how to change kernel runtime parameters in a persistent and no persistent way. You can use the command line in a running system to alter certain runtime kernel parameters as a onetime modification or permanently by editing a configuration ration file. Thus you are allowed to enable or disable kernel parameters on the fly without much difficulty when it is needed due to a required change in the way the system is expected to operate. The latest specification of the file system hierarchy standards indicates that Proc represents the default method for handling process and system information as well as other kernel and memory information. Particularly the Procsys is where you can find all the information about devices, drivers and some kernel features.
The actual internal structure of Proc sys depends heavily on the kernel being used, but you are likely to find the following directories inside. In turn each of them will contain other sub directories where the values for each perimeter category are maintained. So slashdev they have perimeters for specific devices connected to the machine. FS is the file system configuration, it has Kodas and inodes for example kernel is the kernel specific configuration, net will have the network configuration and VM will have the use of the kernel virtual memory.
So to modify the kernel runtime parameters we will use the sysctl command. The exact number of the parameters that can be modified or that can be that can be modified can be viewed with this command sysctl a WC l. If you want to view the complete list of kernel parameters you can do sysctl a and as you can see that was a lot of parameters. So what you can do is you can pipe it to less and then it’ll go one page at a time.
Let’s take a look at the first few lines we have the information like debug exception trace is set to one right now which is enabled and debug panic on RCU stall is set to zero which is disabled. And these are the kernel parameter values that you can change from enabled to disabled. The command we’re going to use is systole dev CDROM auto close. So we’re going to change the parameters and as you can see the autoclode is turned enabled now. Okay and now we’re going to run another parameter change sysctl net IPV four IP underscore and that is set to one as well. So now look at let’s do a cat on auto close and you see there’s a value of one that’s showing enabled. We’ll do the same for the other one. Also catrocksysnetipv four IP underscore and that’s also set to one. So this is how the colonel can be modified while the system is running.
Now instead of a non-persistent, if you want to make a persistent change then you have to actually go into the file and the file that deals with it is etc sysctl. com. So if you take a look at it. It’s not a huge file, but it has the parameters that can be changed. And right now, as you can see, most of these, like this one that we have changed, it’s commented out, so it won’t execute. If we were to reboot the system, our change will be lost. So if you want to change it, just remove this comment and then you’ll be okay. So this is where you make persistent changes that can last a reboot.
So sometimes you want to know the related package of a file before installation or when it is already there. This is of great help during system hardening or general system cleanups. In this lecture we have a look at several ways to determine the relationships between files and the packages they belong to. We are going analyze this into both stenos based red hat based systems as well as Ubuntu. So to show the files that are in a package, we can run the Rpm command rpm.
Actually I have a long file name, so I have it typed here. So if I were to run Rpm QL and then the name of the package, this package I’ve checked that it’s installed on my machine and hit enter, it’s going to show you the files that are residing in that package. What you can do is turn it around and do an Rpm QF on the actual file name. This is out of the three files that were showing earlier and this will give us the package name. So you can do it both ways. Run the package to find the files and if you have the file name, you can find which package it belongs to.
And with Yum, you can do a similar request to see the related package. So we can do Yum what provides it’s all, one word bin PS. And I’ll show you what are the related files with this? That’s another way of checking this. So on a DVN machine or Ubuntu machine we can run Dpkg, dpackage S, capital S. And suppose we are looking for the file ATD user s bin ATD and it tells you that it’s located at that location. And if you want to look at the files that are installed by a package, we can do DP Kg, capital L-A-T. And these are all the files that get installed in this package.
In this lecture we’re going to talk about locating and analyzing log system log files. So Linux system administrators often need to look at log files for troubleshooting purposes. And this is the first thing any system administrator should be doing actually if there’s a problem. Linux and the applications that run on it can generate all different types of messages which are recorded in various slog files. Linux uses a set of configuration files, directories, programs, commands and demons to create, store and recycle these log messages. Knowing where the system keeps its log files and how to make use of related commands can therefore help save valuable time during troubleshooting. So the default location for log files in Linux is VAR log. You can view the list of log files in the directory with a simple LS l varlog. It gives you the list of all the log files that are there.
So some of the common files that you’re going to find in here is like WTMP the WTMP file and there’s another one called UTMP which is not. In here are files which keep track of users logging in and out of the system. You cannot directly read the contents of these files using cat. There are specific commands for that. We’ll now use some of these commands to see who is currently logged into the Linux server. Simply use the who command. This command gets its value from the VAR run utmpmp for ubuntu. So if I were to run a who command the only user that’s logged into this machine recognize myself. So it’s only going to show one instance of root. What I have done is I have used another system and I did an SSH into this machine. So let’s see if we have a non root user on this machine as well. So as you can see we have a non root user who’s logged into a different, logged in from a different IP address into this machine.
So now we have two users, one root user and one non root user. If we use the last command it tells us the login history of the users. So grep suppose if I want to do Larry and these are the two instances that Larry has logged in on this machine suppose I want to look at the last reboot. These are three instances that the reboot has been done on this machine. And if I want to look at when did somebody last log into the system? You can use last log and a lot of these of course the last person is Larry, but a lot of these are system logins as well.
This is system programs, FTP and games and nobody, I mean this is not people, it’s the system internal logins. The most typical use of messages file is the tail. And I want to do a tail of VAR log messages and it shows you the last ten lines of the VAR log messages file. So at the heart of the logging mechanism is the RSS log demon. This service is responsible for listening to log messages from different parts of a Linux system and routing the messages to an appropriate log file in the viral log directory. It can also forward log messages to another Linux server in a sentos machine or red hat. The configuration file for RSS log is Rsslog. com which is located under etc on a bunch of machine is Rsyslog d fifty default. com. So we can take a look at what Rsyslog looked like.
So if we go through the parameters in here we can pick some examples. Like for instance this is kernel is commented right now but any message coming from the Linux kernel will go to this and they should be auth. These are messages coming from authorization and security related events. Mail is messages generated by the mail subsystem cron would be the Cron demon later to messages and local seven is reserved for local use.
Popular posts
Recent Posts