Hey guys and welcome back. So in the previous nugget we learned a little bit more about
the kernel modules. We could see how we could manually intervene and load and remove and
list these modules but we understand that the kernel itself largely is going to work
in an automatic fashion. This is just making your life much much easier we don't have to
think so hard so it really is quite handy. But now we have that information under our
belt. I want to turn our attention to some general kernel configuration information.
So the first thing I want to talk to you about is a particular location and that location
is in the proc directory and then the sys directory and then the kernel directory. Now within here
we're going to house what are effectively the live settings that are running for the kernel.
Now one thing to note is that these settings are very different from the actual modules themselves
to try not to confuse the two. So if I would happen to go in to this particular directory
go into the proc directory and then into sys do an ls we see we have our kernel directory right
here. Right here we can see a whole bunch of configurations and options relating to how our
kernel is going to operate. So things like the bootloader type or the bootloader version
or maybe the maximum amount of threads all of this information we can find within this location
right here proc sys kernel. Now like I say these actually denote settings which are running live
on the system right now. Now if you actually want to make changes to the system such that the changes
take effect when the boot operation starts we would have to use a very particular configuration
file so let me show you what this file is going to be going to be in the sys directory which
should come as no surprise this is a system-wide configuration file and we go into sysctl.conf
and again like I say this file right here is where you can tell the system when it boots up
how you want all the settings within proc sys kernel how you want those settings to be stored
and you can make this permanent by making these changes within this file right here. So if we go
to the sys directory doing ls and in fact let me just grip for sysctl notice we have our sysctl
conf file so if I happen to go in here and hit enter notice this is the configuration file for
system variables and we can do things like setting the kernel domain name or we can allow for certain
activities say for example if we want to have packet forwarding i.e network address translation
this is something we talked about in the lpik one examination we could for example uncomment out
this line and allow for this setting to take place upon boot now notice that this is all in this file
right here but actually it's worth noting is that we also have this sysctl.d what this is is basically
a directory now the thing to note about this directory is that within this directory you
can ultimately specify similar settings so again i go into my directory and to enter we do an ls we
see multiple configuration files for different operations but really what i want to stress is
that if you happen to make some type of configuration change to a file within this directory and it
happens to conflict with something you have specified directly in the sysctl.conf file understand
that the sysctl.conf file is going to take precedence i.e anything within this file right here
will override anything you have within the sysctl.d directory so this conf file is going to take
priority if we have additional information which is not specified here but is specified in the
directory then that can take effect but any conflicts are going to be resolved by having
the sysctl.conf file take that priority now one thing to note is that we can actually make such
changes manually using a particular command as opposed to modifying a configuration file
and that is by using the sspin sysctl within the sspin directory so let's actually explore
this command right here then so what i will do i'll just clear my screen and what i'll do is i'll
actually go back to my home directory right now and i'll just say man sysctl now it's going to say
here this command allows us to configure kernel parameters at runtime and the parameters are
going to be located again within proc sys and note we can use this command to both read the sysctl
data as well as to write new sysctl data so if we happen to scroll on down we're going to see a
whole bunch of different options here is one right here dash a or dash dash all this is going to
allow us to display all the values currently available so if we happen to try and use this one
so sysctl dash a these are all our current kernel settings right now so things like net ipv4 ip
forwarding this is set to the value zero pretty much this means this is inactive and not enabled
this behavior so we could make a change to this behavior directly within the sysctl.conf
file which would allow this behavior to stick and be persistent over multiple reboots or we could
change this behavior in real time using the sysctl command so if i would happen to take
this configuration right here let me copy this and if i wanted to write a new change using the sysctl
command again if i check the man page we can see we have the dash w option or dash dash right and
this is going to allow us to ultimately write in particular changes so let's press q clear the screen
i'll say sysctl dash w to write a change and now i'll actually type in the value i want to modify so
i'll paste this in open i've pasted this in and correctly what i want to do is to actually get
rid of the spaces here and i'll actually modify the value so that it is one instead so if i hit
enter now notice the value has indeed been updated so if i now do sysctl dash a and in fact let me
just grip for the word forwards and that's that's still a little bit too verbose just to make it a
little bit easier i'll say grip ip forward we can see the actual value here has now been modified
and again if we wanted to make this change persistence so that it takes effect when the
system is booted up or rebooted whereabouts would we make that change well we know it's going to be
an xt sysctl dot conf in this case here we could just uncomment this out and save the file to get
the similar effects but with persistence now another thing which i want to talk to you about
that is very important with respect to the kernel is udev now in modern linux systems
the files that we have within the dev directory ultimately tell us what is attached to our system
so imagine something like say a usb gets attached information relating to this device is going to
be within the dev directory now we have this daemon called udevd and this actually works
directly with the kernel so that we can manage the files that we would have within the dev directory
so you can imagine udev as a type of watchdog and if a particular device is attached to our system
udev is going to watch the system and then load in the kernel module that happens to be needed
so again the example being usb is plugged in udev notices this and then loads the necessary
usb module into the kernel and everything works on the fly this is what i'm talking about with the
automated process udev is making this much much easier for us than having to manually go in locate
a particular kernel module and load it in as appropriate now similarly if you happen to remove
that usb stick udev again is going to handle the kernel module and remove that module since it's
no longer needed and we know that the kernel is indeed modular so if this particular module is
no longer needed then strip it down and keep things more efficient again everything handled under
the hood by udev or the udevd daemon so if udev is looking for what exactly is plugged in how do we
see as the system administrator what those devices actually are well we do have a bunch of options
available to us and tools to help us with this task the very first one is ls usb now you can
probably guess what this actually does from the terminology we have ls that is going to list and
we're going to list the usb devices attached to our system so what i could do is say man ls usb
and we can see here this is a utility for displaying information about the usb buses in the system and
devices connected to them and we can see all these additional options that we have to get
different types of information so if i press q and i shoot the command ls usb what i'm actually
seeing right here is information relating to my virtual machine this is because i am running
zbuntu on virtual box but if this happened to be a real-life physical machine then of course i would
get information relating to that instead now the other command we have available to us is ls pc i
if i say man ls pc i again similar to ls usb this is not going to show us usb buses but instead pc
i buses in the system and the device is connected to them and again just like we saw before we have
a whole bunch of different options if i scroll on down we can do things like be verbose or be very
verbose or show kernel drivers so on so forth if i press q i can say ls pc i we can see all the pc i
information i can say ls pc i with a dash v to get more verbose information or i can say dash k to get
the kernel related information with respect to the pc i devices now another command we have
available to us is ls dev this is not going to be installed by default but what i can do is say
apt install proc info and to enter so now if i say man ls dev we can see here this is going to give us
information relating to installed hardware so we'll see things such as interrupt requests
and direct memory access channels so if i happen to use this command ls dev we can see all of that
information now the way the ls dev command actually worked is that it's going to gather
information from some particular locations and these locations will be within the proc directory
so for direct memory access it will be in proc dma for our input output information we will get it
from proc i o ports to show the input output and with respect to our interrupt requests the ls dev
command will look into the proc folder and then the interrupts file now one thing you may notice
with respect to the ls dev command is that it's a very simple command it does not have any additional
options i.e if you happen to do ls dev dash maybe s it actually has no effect on the output we get
the exact same output similarly if you do dash q the exact same output or dash f or dash y it really
is a singular command pulling from those files now one more command we have to understand that is
very important with respect to you dev in fact i should clarify we're going to have two important
commands the first of which is going to be a deprecated command that is no longer recommended
but again we have to understand it for the purposes of the exam and the second command is the modern
way to use the command so the first one is going to be you dev monitor all one word this is going
to allow us to see real-time information relating to our devices as we plug stuff in and unplug them
so say for example you run you dev monitor and you plug in a usb stick this information in real
time is going to be displayed when you are running the you dev monitor command and again like i say
this is a deprecated implementation so you may see it on older linux systems but this is not the
recommended way any longer instead we have the command you dev a dm for administrator and then
a space and then the word monitor this is the modern way to get the same type of information
so if we happen to run this command i'll say you dev monitor which is the deprecated way notice it
says the command is not found but if we happen to say you dev adm space monitor we are now waiting
and are ready to receive any real-time information relating to our devices as they're plugged in and
plugged out again now as it transpires i am on a virtual machine i'm not going to be attaching
any usb's but if i did you would know that this information would be ultimately reported to me
on my terminal window via the udf adm monitor command so this really is a valuable tool for us
as linux systems administrators to be able to monitor our system as external devices are attached
and detached okay doctor that is us for kernel configuration options we still have
more information to get to so how about we keep on going so i hope this has been informative for you
and i'd like to thank you for viewing