Hey guys and welcome back.
So in the previous nugget we had talked about the init tab file which is what the init process
would originally consult when beginning to boot up.
Within that nugget however we also mentioned the concept of some type of setup scripts.
These are ultimately programs that run that will execute multiple commands or start multiple
processes and for the purposes of the Lpik2 examination we have to understand what these
boot scripts are and how they may differ depending on the type of distribution you have.
Now one thing to mention when we're talking about this which is definitely relevant is
how Cysfianet actually operates.
So Cysfianet is not the most efficient way to start up your system and in fact this is
one of the reasons why Cysfianet was ultimately replaced but the way it would operate it would
operate any linear fashion.
So what do I mean when I say linear?
Well it would start the init process and it would tell if I could write correctly the
init process.
So that could be process number one and then after that was done it would begin process
number two, whatever that may be and then process number three and then number four and then
number five and then six.
You kind of get the drift after number one had kicked off and done its thing.
Number two followed and then number three and then number four, number five and when
you happen to have lots of processes that have to be run.
This is quite slow, quite sluggish and definitely inefficient so just something to be aware of.
This is how the process actually happens when you're using a Cysfianet system.
Now how does Cysfianet determine which processes to run and in which order i.e. what should
I run and what should I run first and then second and then third and not just in some
random order because of course certain processes rely on other processes so the order is indeed
importance.
So this is what we want to talk about primarily in this nugget right here.
We have two different locations where init is going to look.
If we happen to be looking on a red hat based distribution the location is going to be different
than if we are looking on a Debian based distribution.
So if you happen to be using a Debian based system the location where the init process
is going to look is going to look in the exe directory and then the init.d directory.
However if we happen to be using a red hat based system again we look in the exe directory
but we then look in the rc.d file or rather rc.d directory my apologies.
So let's talk about two important scripts that you would find on a red hat based system.
So the first script I want to talk to you about is in the exe directory.
It's going to be in rc.d because we're talking about red hat systems and the first script
is going to be rc.sys init.
What this one is all about it's designed to effectively load the system to a very simple
state that is quite honestly the same as run level 1 a single user mode and all this script
is going to do is going to perform actions such as mounting file systems and enabling
devices such as RAID devices and logical volume manager and starting up some essential
system services.
Now for real world purposes this script right here happens to be what is known as a bash
script i.e. it is written using the born again shell and you are very very unlikely to modify
the contents of this bash script but as an administrator you may have to be able to look
into this file and do a little bit of detective work in the event that you have some issues
booting up your system.
The next one again in the exe directory is going to be in rc.d and this one is just called
rc.
Now whenever we are on run levels 1 to 6 this script is going to be executed.
Now this script itself will not do anything on its own you actually have to pass a particular
value to this script such as 1 or such as 5.
Recall what we saw in the init tab file in the previous nugget.
Within this file here this is where you would specify a particular argument.
Now what this actually means say for example we had l3 which would be the id and then run
level 5 and then the weights action and then we could specify exe rc.d.rc and then we could
provide an argument number 5.
We are basically giving the argument 5 to this script.
For run level 5 we are going to use the weights action i.e. allow it to complete and this
script is ultimately going to find additional script to help us load into the correct specified
run level in this case here run level 5.
We will actually find directories within this directory and it is going to follow a very
particular format.
The format would look something like say this rc0.d and rc1.d and maybe rc5.d get the drift.
These are directories which actually correlate to a particular run level i.e. within this
directory here this would be files relating to run level 0 whereas in rc5.d this would
be a directory for run level 5.
Now within these directories what you are going to find are symbolic links.
Now these symbolic links ultimately relate to the starting of processes as well as the
killing of processes which might sound a little bit dramatic but ultimately starting processes
and stopping processes.
Now these symbolic links are going to follow a very particular format.
If the symbolic link happens to begin with an s then this is going to point to a process
relating to starting a process and if the symbolic link begins with a k you can guess
this actually relates to killing processes.
So all these symbolic links do is they point to scripts and these scripts handle these
tasks i.e. starting things or stopping things.
But if we happen to see a symbolic link which was k and then maybe the number 9 and then
maybe i don't know nginx we can infer by the formatting of this symbolic link of what it's
actually doing we see a k so we know this sim link is pointing to a script which is going
to kill a particular process.
We get the number here which is the numerical number remember 6 feet and it operates in
a sequential manner.
Process 1 will go before process 2 in this case here we have process 9 so after process
8 begins this particular one will execute and it's going to kill the nginx process.
So like i say on modern systems the sysv init program is ultimately outdated and has been
replaced with system d but nevertheless we can get a rough idea of what this looks like
even on a modern system so what i'll do is i'll go into the etsy directory and if i happen
to go into maybe say rc3.d what this is is scripts relating to run level 3 whereas if
i happen to go in let's say rc5.d this would be scripts relating to run level 5 now if
i do an ls we can just see a whole bunch of water sim links if i do an ls-l for the long
listing we can actually see where these sim links are pointing to now notice because this
is a debian based system these are actually pointing to init.d whereas this would be different
within a red hat based system.
Now notice we have the value k this means that this is relating to killing processes
whereas the other ones here these are all beginning with s these are for starting processes
and the next one is the value the process number now you might notice that these all appear
to be starting at the same time we are now on a modern system debaist system and things
can actually operate in parallel so we're no longer hamstrung by the older implementation
of sysvian.net so that is what i'm saying that the example here is not exactly perfect
because we are talking about older outdated technology which frustratingly is still a
big part of the lpik 2 examination of course but that is what you're seeing when you see
these discrepancies we are ultimately mapping old technology onto new technology so if i
happen to open up one of these scripts right here so i'll say nano s01 acpid and hit enter
what you are looking at here is a bash script this is ultimately just a file full of programming
logic to do certain things such as loading particular modules and starting and stopping
particular processes so on and so forth and ultimately this is what all of these files
look like they're all bash scripts again we go into maybe say s1 cron same type of deal
we are just running a script to stand up the cron service a whole bunch of programming
logic within here now if we wanted to control a particular action maybe we wanted to change
the rsync from starting up what we could actually do is we could rename the sim link now the
sim link happens to be s01 rsync what if we happen to change that so i said s01 rsync
and i changed it to k01 rsync what i need to do of course is to do super user privileges
because i'm in the etsy directory let me just type in my passwords and now if i do an ls-l
we can see here rsync has a sim link beginning with k so what this means is that when we
happen to drop into our particular run level this is run level 5 instead of starting the
rsync program we would happen to stop it now the issue is here is that whilst we can manage
these processes we can ultimately invoke scripts to start or to kill particular applications
and actions this is not the most friendly way to manage such a thing just by renaming sim
links things can be confusing and by the way on older systems whereby we had to use this
particular action i.e. when we were using sys the init-based systems whereby the processes
were not parallel they were sequential and the order of operations mattered much much more
by renaming sim links if we happen to maybe use the wrong number we could actually change the
order of operations and if some processes relied on another process standing up and we got
the order wrong then well we could definitely cause some issues but the good news was for system
the based administrators they did actually have the ability to use some particular tools to simplify
this action now what exactly were those tools how were they used well that's what we're going to be
talking about in the very next nugget so i hope this has been informative for you and i'd like to
thank you for viewing