Dependency Issues Part 2

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or

Already have an account? Sign In »

Time
21 hours 25 minutes
Difficulty
Intermediate
Video Transcription
00:00
>> Hey, there cybrarians and welcome back to
00:00
the Linux plus course here at Cybrary,
00:00
I'm your instructor Rob Goelz.
00:00
In today's lesson, we'll be taking on
00:00
>> Part 2 in this two-part series on dependency issues.
00:00
>> Upon completion of today's lesson,
00:00
you are going to be able to identify dependency issues
00:00
>> that are related to versioning,
00:00
>> libraries, GCC compatibility,
00:00
>> and/or environment variables.
00:00
>> We're going to see how we can locate files
00:00
>> and run commands to troubleshoot dependency issues.
00:00
>> Another consideration when we're looking at
00:00
these dependency issues is the version
00:00
of software that's included in a package.
00:00
Now versioning or numbering really is just the way
00:00
that multiple application updates are tracked.
00:00
This version number can determine
00:00
>> if your system has up-to-date packages or patches
00:00
>> or if they require an update.
00:00
To see this information,
00:00
if we're on an RPM-based system,
00:00
we can see that information with
00:00
RPM-q and the package name.
00:00
We saw this in the previous lesson as well.
00:00
>> It's very helpful.
00:00
>> Now systems that use yum can also use yum history info
00:00
>> and they can pass the package name to that as well.
00:00
>> If we're on an APT-based system,
00:00
we can find version information
00:00
>> in var/log/apt/history.log.
00:00
>> Now when we're looking at software versions,
00:00
we also might want to consider
00:00
the involvement of libraries.
00:00
This is because application functions are
00:00
generally split into library files
00:00
>> so that applications using the same function just
00:00
>> share the library files, hence, shared libraries.
00:00
Now if an application starts having issues
00:00
>> after a patch cycle,
00:00
>> it could be related to a shared library
00:00
>> that's used by the application.
00:00
>> You're definitely going to want to check into that
00:00
>> and you can see which libraries are used by
00:00
>> the application with the ldd command.
00:00
You could run ldd and then pass
00:00
the application name to that or better yet,
00:00
you might want to save that information in a file.
00:00
I know for me it's better to have something
00:00
saved in a file so I can refer back to it
00:00
>> rather than having to go back to the system
00:00
>> and run the command just on the fly
00:00
>> and look at the console output.
00:00
>> You can do ldd an application name
00:00
and then use a greater than sign
00:00
or double greater than sign and put it in a file,
00:00
>> for example, app_lib.out.
00:00
>> Then you can refer back to that file
00:00
>> and you capture the information there
00:00
>> for use later to troubleshoot.
00:00
Finally, the GNU Compiler Collection, or GCC,
00:00
>> is the most common tool for compiling Linux.
00:00
>> That being said, users have run into
00:00
some issues compiling with GCC
00:00
>> because it uses the system C library
00:00
>> and that may not be compliant with ISO standards.
00:00
>> That's because GCC uses corrected versions
00:00
of system header files and that causes issues.
00:00
There's also compatibility issues with GNU C
00:00
>> and other non-ISO versions
00:00
>> of the C programming language as well.
00:00
This is just something to keep in mind,
00:00
the GCC compiler is very, very common.
00:00
You will see it a lot,
00:00
>> but you may write compatibility issues.
00:00
>> Be aware that it may not be complied with ISO
00:00
>> and it may not play nice with other children.
00:00
>> It's just a little bit funky that way.
00:00
Of course, as with any package,
00:00
that GCC package should be kept up-to-date.
00:00
Finally, the last cause of dependency issues
00:00
>> we may want to talk about here
00:00
>> is our environment variables.
00:00
>> One thing we've covered previously
00:00
>> is the path variable.
00:00
>> We talked about that in Module 23.
00:00
That path variable defines
00:00
>> which directories are searched
00:00
>> whenever a user tries to run a command in bash,
00:00
>> and maybe bashes and
00:00
doesn't know how to handle that command.
00:00
By default, it goes looking in that path
00:00
variable to figure out where the command is.
00:00
If the application or command
00:00
the user is trying to run is not the path,
00:00
then the application won't run,
00:00
you'll get an error message.
00:00
Now, there's a couple of ways that you could fix this.
00:00
If you wanted to modify the path for every user,
00:00
you can edit: /etc/profile.d.
00:00
But if you want to modify the path
00:00
for an individual user,
00:00
you're going to go into the user home directory.
00:00
Remember that the shortcut for that is Tilda/
00:00
>> that indicates home, then the username.
00:00
>> User home directory.profile
00:00
>> or user home directory.bash_profile
00:00
>> based on whichever distribution you're in,
00:00
is how you can modify that path for an individual user.
00:00
In this lesson, we covered
00:00
>> other types of application dependency issues
00:00
>> that you may need to troubleshoot.
00:00
>> Then we talked about identifying
00:00
issues related to versioning,
00:00
libraries, GCC, and environment variables.
00:00
Then finally, we talked about locating files
00:00
>> and running commands to troubleshoot dependency issues
00:00
>> such as ldd and looking at
00:00
>> /etc/profile.d,-/profile.-/.bash_profile
00:00
>> for fixing path issues.
00:00
Thanks so much for being here
00:00
>> and I look forward to seeing you in the next lesson.
Up Next