Dependency Issues Part 1
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 »
Video Transcription
00:00
>> Hey, Cybrarians. Welcome back to
00:00
the Linux plus course here at Cybrary.
00:00
In today's lesson, we're going to be discussing
00:00
dependency issues in part 1 of our two-part series.
00:00
Upon completion of today's lesson,
00:00
you're going to be able to identify
00:00
dependency issues that are related to patching,
00:00
updates, and repositories,
00:00
and then locate files and run
00:00
commands to troubleshoot dependency issues.
00:00
Dependencies are major issues when we're dealing
00:00
with applications and software packages.
00:00
Sometimes you have the benefit
00:00
>> of using a package manager
00:00
>> like yum or apt, which handles dependencies.
00:00
However, even they cannot solve all issues.
00:00
In this lesson, we're going to look at
00:00
several items that can cause
00:00
dependency issues or be involved
00:00
>> with dependency issues,
00:00
>> such as patching, update issues, and repositories.
00:00
In software and application management,
00:00
a patch just refers to a file that updates
00:00
a program or makes a configuration file change.
00:00
Now, this can correct problems or include bug fixes,
00:00
but patches are most often deployed when we're trying
00:00
to resolve a security vulnerability on our system.
00:00
Patching is just the process of applying the patch.
00:00
But we generally also want to have
00:00
>> a patching policy and
00:00
>> think about things like how often do we
00:00
want to apply patches monthly,
00:00
weekly, maybe every night.
00:00
When does this patching occur?
00:00
Can we do it during the daytime
00:00
or do we need to wait until
00:00
overnight or off-hours so
00:00
we don't impact the users on the system?
00:00
Which systems get patched and in what order?
00:00
Are we able to test dev prod or dev-test prod?
00:00
What order do we need to do this in order to
00:00
make sure that these patches don't impact
00:00
our applications and we can test them that they're
00:00
not working properly after we patch?
00:00
But even once you make all of these decisions,
00:00
organizations with an effective patching policy can
00:00
still fall prey to bad patches.
00:00
Every once in a while, vendors just
00:00
release a stinker and you're stuck
00:00
with a bad patch that causes
00:00
>> instability on your system.
00:00
>> If you see an issue after a patch cycle,
00:00
you're going to want to look and see what changed.
00:00
Now, if you know that there is
00:00
probably a suspect package,
00:00
you can look for that package with
00:00
RPM-q and then the package name or yum info list,
00:00
and then the package name on RPM-based distributions
00:00
and on an apt-based or DPKG-based distribution,
00:00
you can grep for package name
00:00
>> in var/log/apt/history.log.
00:00
>> Now when patching a system,
00:00
you may also run into issues applying updates.
00:00
Some of these can be annoying or
00:00
innocuous and easily fixed.
00:00
These are things when you're trying to
00:00
access the repo containing the update and it's
00:00
unavailable or you just don't have permission
00:00
to install the update. There's ways around that.
00:00
Maybe it's a networking issue,
00:00
maybe you just need to talk to somebody
00:00
about getting your permissions fixed,
00:00
but other update issues are more severe.
00:00
We talked about the bad patch and that could
00:00
break software or the operating system itself,
00:00
or maybe it overwrites your configuration files,
00:00
data, or databases.
00:00
Now, all updates do have the potential
00:00
to alter the way a program operates.
00:00
Make sure users are aware
00:00
of the changes that are taking place.
00:00
A good change management process should make
00:00
people aware and all stakeholders
00:00
aware of changes that are being made.
00:00
Users are going to be
00:00
the first ones to tell you when things
00:00
aren't operating the way that they normally work.
00:00
Now, the best way to mitigate the risk of
00:00
a failed update is to have
00:00
a good working backup available.
00:00
But another recommended option is to always have
00:00
a feasible rollback plan so you can get
00:00
back to where you were quickly and if you're able to,
00:00
use snapshots because in most cases,
00:00
snapshots are going to be
00:00
your friend in terms of doing a rollback.
00:00
Now, package managers depend upon
00:00
repositories that actually
00:00
store the software information.
00:00
Accessing the repositories generally
00:00
requires a network connection.
00:00
If you receive an error from
00:00
the repository, check the network.
00:00
We talked a little bit more about
00:00
network troubleshooting in Module 21.
00:00
Now, the package manager itself can also get corrupted.
00:00
Luckily, there are a few commands you can use to
00:00
resolve these types of issues
00:00
>> on local package managers.
00:00
>> For example, if you're using
00:00
an RPM-based distribution with yum,
00:00
you can reuse yum clean all
00:00
or DPKG-based distribution with app,
00:00
you can run apt clean.
00:00
Also, keep in mind if you're installing a package
00:00
that is from a non-risk standard repository,
00:00
what you have to do is add or enable
00:00
that repo so that you can actually access that package.
00:00
If you're using RPM-based distribution with yum,
00:00
you could use yum-config-manager and then add the repo.
00:00
So add-repo and provide the repo URL.
00:00
But if you're on a DPKG-based distribution,
00:00
you may actually need to go in and edit manually the
00:00
etc/apt/sources.list file and add
00:00
the repository information there.
00:00
With that, in this lesson, we covered the types of
00:00
application dependency issues that
00:00
you may need to troubleshoot.
00:00
We talked about identifying issues
00:00
related to patching and updates.
00:00
Then finally, we talked about
00:00
>> locating files and running
00:00
>> commands to troubleshoot
00:00
these types of dependency issues.
00:00
Things like rpm-q,
00:00
looking at var/log/apt/history.log,
00:00
and then running yum clean all an apt
00:00
clean to repair package managers.
00:00
Thanks so much for being here and I look
00:00
forward to seeing you in the next lesson.
Up Next
Instructed By
Similar Content
