Using Name Resolution Tools
Using DNS for name resolution works great—unless it doesn’t work
correctly, that is. Then it can be a royal inconvenience for you
because your end users won’t be able to check their stock prices or
manage their fantasy baseball team. Fortunately, there are several
tools you can use to troubleshoot name resolution on your network:
• dig
• host
• getent
dig
You can use the Domain Information Groper (dig) utility to perform a
DNS lookup on your DNS server and display detailed information about
the hostname being resolved and about the DNS server itself. If you
don’t specify a particular DNS server with the dig command, the DNS
servers configured in the resolv.conf file will be used. The syntax is
dig @dns_server hostname
An example is shown in Figure 15-18.
The output from dig is considerably more extensive than that displayed
by other DNS troubleshooting tools such as nslookup and host. The
dig command returns the IP address associated with the hostname in the
ANSWER SECTION. It also lists the authoritative name server for the
hostname and zone in the AUTHORITY SECTION.
You can use the following options with dig:
• a
Resolve A record information
• ptr
Resolve a PTR record
• cname
Resolve CNAME record information
• in
Resolve Internet record information
• mx
Resolve MX record information
• soa
Resolve start of authority information
You can also use the host command to resolve hostnames.
Whereas the dig command provides extensive name resolution information, host
provides simple, quick information. The syntax is similar to that used
with dig. You enter
host hostname DNS_server
at the shell prompt.
Again, if you don’t specify a DNS server, the default DNS server specified in
/etc/resolv.conf
will be used.
An example of using host is shown here:
openSUSE:/ # host www.google.com
www.google.com has address 74.125.239.49
www.google.com has address 74.125.239.48
www.google.com has address 74.125.239.50
www.google.com has address 74.125.239.52
www.google.com has address 74.125.239.51
www.google.com has IPv6 address 2607:f8b0:4005:800::1011
getent
In addition to host and dig, you can also use getent to test your name
resolution system. One of the weaknesses of the host and dig commands
is that they don’t actually follow the same process for name
resolution as applications and services running on your system do.
If an application such as a web browser needs to resolve a hostname to an
IP address, it first queries your
/etc/hosts
file. If an entry for the host in question can’t be found there, it uses the DNS server you
configured to resolve the hostname.
However, the dig and host commands don’t do this. They skip the hosts
file completely and go directly to your DNS server to test name
resolution. This is an issue of concern! Many phishing and pharming
attacks exploit the hosts file to redirect URLs to malicious websites
where users’ personal information can be gleaned. As you can see,
using host or dig will not reveal such an attack because they don’t
look at the hosts file.
The good news is that getent does. The syntax for using getent to test
name resolution is to enter
getent hosts hostname
at the shell prompt.
An example is shown next:
openSUSE:/ # getent hosts router1
10.0.0.1 router1
In this example, an entry for the router1 hostname exists in the hosts
file, so getent was able to grab it and display it on the screen.
If the hosts file doesn’t have an entry for the hostname specified, it
will try to resolve it via DNS, just like a regular application would.
An example is shown next:
openSUSE:/ # getent hosts www.nebo-tech.com
98.139.135.199 sbsfe-p11.geo.mf0.yahoodns.net www.nebo-tech.com
TIP The getent command can query any data configured in your
/etc/nsswitch.conf
file. For example, you can enter
getent passwd
at the shell prompt to pull entries out of your passwd file.
LX0-104 Exam Objectives (T)
Showing posts with label troubleshooting. Show all posts
Showing posts with label troubleshooting. Show all posts
Monday, December 19, 2016
Troubleshooting Network VI
Using nc
The netcat command (nc) is a very useful tool for testing network
communications between hosts. It goes one step beyond the ping command
and actually establishes a TCP or UDP connection between two network
hosts. One way to use this command is to open a listening TCP or UDP
socket on one host, and then connect to that socket from another host.
In the following example, I first open a TCP listening socket on one
of the hosts being tested:
openSUSE:/ # nc -l 2388
The
–l option
tells netcat to listen for incoming connections instead of trying to establish a connection with another computer. Because I didn’t specify a protocol, TCP is used by default.
If I wanted to use UDP, I would need to include the
–u option with the command.
I also specified the IP port to listen on (2388).
With a listening socket established on one system, I can then connect
to it from another system and establish a TCP (or UDP) connection
using the nc command again. This time, I enter the following:
[root@fs5 ~]# nc 10.0.0.83 2388
This command tells nc the IP address of the host to connect to and
which IP port to use. Once the connection is established, I can type
text at the prompt of the second system and see if it appears on the
screen of the second system, as shown here:
[root@fs5 ~]# nc 10.0.0.83 2388
This is a test.
openSUSE:/ # nc -l 2388
This is a test.
LX0-104 Exam Objectives (T)
The netcat command (nc) is a very useful tool for testing network
communications between hosts. It goes one step beyond the ping command
and actually establishes a TCP or UDP connection between two network
hosts. One way to use this command is to open a listening TCP or UDP
socket on one host, and then connect to that socket from another host.
In the following example, I first open a TCP listening socket on one
of the hosts being tested:
openSUSE:/ # nc -l 2388
The
–l option
tells netcat to listen for incoming connections instead of trying to establish a connection with another computer. Because I didn’t specify a protocol, TCP is used by default.
If I wanted to use UDP, I would need to include the
–u option with the command.
I also specified the IP port to listen on (2388).
With a listening socket established on one system, I can then connect
to it from another system and establish a TCP (or UDP) connection
using the nc command again. This time, I enter the following:
[root@fs5 ~]# nc 10.0.0.83 2388
This command tells nc the IP address of the host to connect to and
which IP port to use. Once the connection is established, I can type
text at the prompt of the second system and see if it appears on the
screen of the second system, as shown here:
[root@fs5 ~]# nc 10.0.0.83 2388
This is a test.
openSUSE:/ # nc -l 2388
This is a test.
LX0-104 Exam Objectives (T)
Troubleshooting Network V
Using traceroute
The traceroute utility is really cool. Remember that if you try to
send information to an IP host that doesn’t reside on your local
network segment, the packets will be sent to your default gateway
router. This router will then use a variety of routing protocols to
figure out how to get the packets to the destination system. In the
process, the packets may have to be transferred from router to router
to router to get them there. This is shown in Figure 15-16.
This is one of the beauties of an IP-based network. You can connect
multiple networks together using routers and transfer data between
them. It’s this functionality that allows the Internet to exist. You
can use a web browser to send http request packets to a web server
located somewhere in the world and have it respond with the web page
you want to view. The routing protocols used by routers dynamically
determine the best route for packets to take based on system load. The
route taken can change as network conditions change.
The traceroute utility can be used to trace the route a packet must
traverse through these routers to arrive at its destination. It does
this using the same ICMP echo request and ICMP echo response packets
used by the ping utility, but it manipulates the TTL parameter of
those packets. As a result, an ICMP echo response packet is sent back
to the source system from each router your packets cross as they work
their way through the network to the destination host, providing you
with a list that shows the route between the source and destination
systems.
This utility can be a very useful tool if you’re experiencing
communication problems between networks. The traceroute utility can
help you track down which router in the route isn’t working correctly.
The syntax for using this utility is
traceroute destination_hostname_or_IP_address
When you run it, traceroute creates one line for each router your packets cross as they
make their way to the destination system. This is shown in Figure 15-17.
As you can see in Figure 15-17, the IP address of the router is
displayed along with round-trip time statistics. As with the ping
command, you can also use the traceroute command with the IPv6
protocol. To do this, you run
traceroute6
instead of traceroute.
NOTE
You can also use the
tracepath
command to trace the route to a remote network host. The syntax, functionality, and
output are almost identical to traceroute. As with traceroute, you can run
tracepath6
to use the IPv6 protocol with this command.
LX0-104 Exam Objectives (T)
The traceroute utility is really cool. Remember that if you try to
send information to an IP host that doesn’t reside on your local
network segment, the packets will be sent to your default gateway
router. This router will then use a variety of routing protocols to
figure out how to get the packets to the destination system. In the
process, the packets may have to be transferred from router to router
to router to get them there. This is shown in Figure 15-16.
This is one of the beauties of an IP-based network. You can connect
multiple networks together using routers and transfer data between
them. It’s this functionality that allows the Internet to exist. You
can use a web browser to send http request packets to a web server
located somewhere in the world and have it respond with the web page
you want to view. The routing protocols used by routers dynamically
determine the best route for packets to take based on system load. The
route taken can change as network conditions change.
The traceroute utility can be used to trace the route a packet must
traverse through these routers to arrive at its destination. It does
this using the same ICMP echo request and ICMP echo response packets
used by the ping utility, but it manipulates the TTL parameter of
those packets. As a result, an ICMP echo response packet is sent back
to the source system from each router your packets cross as they work
their way through the network to the destination host, providing you
with a list that shows the route between the source and destination
systems.
This utility can be a very useful tool if you’re experiencing
communication problems between networks. The traceroute utility can
help you track down which router in the route isn’t working correctly.
The syntax for using this utility is
traceroute destination_hostname_or_IP_address
When you run it, traceroute creates one line for each router your packets cross as they
make their way to the destination system. This is shown in Figure 15-17.
As you can see in Figure 15-17, the IP address of the router is
displayed along with round-trip time statistics. As with the ping
command, you can also use the traceroute command with the IPv6
protocol. To do this, you run
traceroute6
instead of traceroute.
NOTE
You can also use the
tracepath
command to trace the route to a remote network host. The syntax, functionality, and
output are almost identical to traceroute. As with traceroute, you can run
tracepath6
to use the IPv6 protocol with this command.
LX0-104 Exam Objectives (T)
Troubleshooting Network IV
Using netstat
The netstat utility is another powerful tool in your virtual toolbox.
This utility can do the following:
• List network connections
• Display your routing table
• Display information about your network interface
The syntax for using netstat is to enter
netstat option
at the shell prompt. You can use the options listed in Table 15-5.
In addition to netstat, you should also be familiar with traceroute.
Let’s look at this utility next.
LX0-104 Exam Objectives (T)
The netstat utility is another powerful tool in your virtual toolbox.
This utility can do the following:
• List network connections
• Display your routing table
• Display information about your network interface
The syntax for using netstat is to enter
netstat option
at the shell prompt. You can use the options listed in Table 15-5.
In addition to netstat, you should also be familiar with traceroute.
Let’s look at this utility next.
LX0-104 Exam Objectives (T)
Troubleshooting Network III
Using ping
The ping utility is my best friend. It is one of the handiest tools in
my networking virtual tool- box. I use ping all the time to test
connectivity between hosts through the network. Ping works by sending
an ICMP echo request packet from the source system to the destination
system. The destination system then responds with an ICMP echo
response packet. This process is shown in Figure 15-13.
If the ICMP echo response packet is received by the sending system,
you know three things:
• Your network interface is working correctly.
• The destination system is up and working correctly.
• The network hardware between your system and the destination system
is working correctly.
NOTE
Be warned that many host-based firewalls used by many operating
systems are configured by default to not respond to ICMP echo request
packets. This is done to prevent a variety of denial of service (DoS)
attacks that utilize a flood of ping requests. This configuration can
give the false impression that the destination system is down. It’s actually
up and running just fine; it’s just that the firewall on the host is stopping
the ping packets from reaching the operating system.
That is valuable information to know! The basic syntax for using ping
is ping destination_ IP_address. This causes ICMP echo request packets
to be sent to the specified host. For example, you could enter ping
192.168.2.1 to ping a host with this address. This is shown in Figure
15-14.
Notice in Figure 15-14 that the results of each ping sent are shown on
a single line. Each line displays the size of the echo response packet
(64 bytes), who it came from (192.168.2.1), its time- to-live value
(63), and the round-trip time (4.25 ms to 1.01 ms).
NOTE
The time-to-live (TTL) value specifies the number of routers the
packet is allowed to cross before being thrown away.
By default, the ping utility will continue sending ping requests to
the specified host until you press
ctrl-c
to stop it. You can use the –c option with the ping command to specify a number of times to ping.
For example, you can enter
ping –c 10 192.168.2.1
to ping ten times and then exit.
You can also
ping hostname
instead of IP address. As long as you’ve configured your system with a valid DNS server address, ping will resolve the hostname into an IP address and send ping requests to it.
This is shown in Figure 15-15.
Pinging with a hostname can be a valuable troubleshooting tool. It
lets you know if there is a problem with the DNS server. For example,
if pinging by IP address works but pinging by host- name does not
work, then you know that your basic network configuration and
connectivity is working properly but there is a problem with the DNS
server.
You can also test IPv6 communications using ping as well. However, you
must use the
ping6
command instead of ping.
LX0-104 Exam Objectives (T)
The ping utility is my best friend. It is one of the handiest tools in
my networking virtual tool- box. I use ping all the time to test
connectivity between hosts through the network. Ping works by sending
an ICMP echo request packet from the source system to the destination
system. The destination system then responds with an ICMP echo
response packet. This process is shown in Figure 15-13.
If the ICMP echo response packet is received by the sending system,
you know three things:
• Your network interface is working correctly.
• The destination system is up and working correctly.
• The network hardware between your system and the destination system
is working correctly.
NOTE
Be warned that many host-based firewalls used by many operating
systems are configured by default to not respond to ICMP echo request
packets. This is done to prevent a variety of denial of service (DoS)
attacks that utilize a flood of ping requests. This configuration can
give the false impression that the destination system is down. It’s actually
up and running just fine; it’s just that the firewall on the host is stopping
the ping packets from reaching the operating system.
That is valuable information to know! The basic syntax for using ping
is ping destination_ IP_address. This causes ICMP echo request packets
to be sent to the specified host. For example, you could enter ping
192.168.2.1 to ping a host with this address. This is shown in Figure
15-14.
Notice in Figure 15-14 that the results of each ping sent are shown on
a single line. Each line displays the size of the echo response packet
(64 bytes), who it came from (192.168.2.1), its time- to-live value
(63), and the round-trip time (4.25 ms to 1.01 ms).
NOTE
The time-to-live (TTL) value specifies the number of routers the
packet is allowed to cross before being thrown away.
By default, the ping utility will continue sending ping requests to
the specified host until you press
ctrl-c
to stop it. You can use the –c option with the ping command to specify a number of times to ping.
For example, you can enter
ping –c 10 192.168.2.1
to ping ten times and then exit.
You can also
ping hostname
instead of IP address. As long as you’ve configured your system with a valid DNS server address, ping will resolve the hostname into an IP address and send ping requests to it.
This is shown in Figure 15-15.
Pinging with a hostname can be a valuable troubleshooting tool. It
lets you know if there is a problem with the DNS server. For example,
if pinging by IP address works but pinging by host- name does not
work, then you know that your basic network configuration and
connectivity is working properly but there is a problem with the DNS
server.
You can also test IPv6 communications using ping as well. However, you
must use the
ping6
command instead of ping.
LX0-104 Exam Objectives (T)
Troubleshooting Network II
Using a Standardized Troubleshooting Model
Being a good troubleshooter is a key part of being an effective Linux
system administrator. I’ve been teaching new system administrators for
nearly two decades now, and this is one of the hard- est skills for
some to master. Some new admins just seem to have an intrinsic sense
for how to troubleshoot problems; others don’t. The reason for this,
in my opinion, is that troubleshooting is part art form. Just as it’s
difficult for some of us (me included) to learn how to draw, sculpt,
or paint, it’s also difficult for some of us to learn how to
troubleshoot.
However, I’ve noticed that, with a little training and a lot of
practice, most new administrators can eventually learn how to
troubleshoot effectively. There are three keys to doing this:
• Using a solid troubleshooting procedure
• Obtaining a working knowledge of troubleshooting tools
• Gaining a lot of experience troubleshooting problems
The last point is beyond the scope of this book. The only way to gain
troubleshooting experience is to spend a couple of years in the
field. However, we can work with the first two points. In the last
part of this chapter, we’ll focus specifically on troubleshooting
network issues. However, the procedure we will discuss here can be
broadly applied to any system problem.
Network problems can be caused by a wide array of issues, and I can’t
even begin to cover them all here. Instead, I want to focus on using a
standardized process for troubleshooting network issues. By using a
standardized process, you can adapt to, confront, and resolve a broad
range of network problems. The model I’m going to present here is by
no means all-inclusive. You may need to add, remove, or reorganize
steps to match your particular situation. However, I hope it gives you
a good base to start from.
Many new system administrators make a key mistake when they
troubleshoot system or net- work problems. Instead of using a
methodical troubleshooting approach, they go off half-cocked and start
trying to implement fixes before they really know what the problem is.
I call it “shotgun troubleshooting.” The administrator tries one fix
after another, hoping that one of them will repair the problem.
This is a very dangerous practice. I’ve watched system administrators
do this and cause more problems than they solve. Sometimes they even
cause catastrophic problems. Case in point: Several years ago I was
setting up several servers in a network. One of the servers was
misconfigured and was having trouble synchronizing information with
the other systems. While I was trying to figure out the source of the
problem, my coworker (let’s call him Syd) started implementing one fix
after another in shotgun fashion trying to get the server to sync with
the other servers. In the process, he managed to catastrophically mess
up all of them! The actual issue was relatively minor and would have
required only about 20 minutes to fix. Instead, we had to spend the
rest of the day and part of the night reinstalling each server from
scratch and restoring their data.
Instead of using shotgun troubleshooting, you should use a
standardized troubleshooting model. The goal of a troubleshooting
model is to concretely identify the source of the problem before you
start fixing things. I know that sounds simple, but many system
administrators struggle with this concept. Here’s a suggested
troubleshooting model that you can use to develop your own personal
troubleshooting methodology:
Step 1. Gather information. This is a critical step. You need to
determine exactly what has happened. What are the symptoms? Were any
error messages displayed? What did they say? How extensive is the
problem? Is it isolated to a single system, or are many systems
experiencing the same problem?
Step 2. Identify what has changed. In this step, you should identify
what has changed in the system. Has new software been installed? Has
new hardware been installed? Did a user change something? Did you
change something?
Step 3. Create a hypothesis. With the information gathered in the
preceding steps, develop several hypotheses that could explain the
problem. To do this, you may need to do some research. You should
check FAQs and knowledgebases available on the Internet. You should
also consult with peers to validate your hypotheses. Using the
information you gain, narrow your results down to the one or two most
likely causes.
Step 4. Determine the appropriate fix. The next step is to use peers,
FAQs, knowledgebases, and your own experience to identify the steps
needed to fix the problem. As you do this, be sure to identify the
possible ramifications of implementing the fix and account for them.
Many times, the fix may have side effects that are as bad as or worse
than the original problem.
Step 5. Implement the fix. At this point, you’re ready to implement
the fix. Notice that in this troubleshooting model, we did a ton of
research before implementing a fix! Doing so greatly increases the
likelihood of success. After implementing the fix, be sure to verify
that the fix actually repaired the problem and that the issue doesn’t
reappear.
Step 6. Ensure user satisfaction. This is a key mistake made by many
system administrators. I like to teach students the adage “If the user
ain’t happy, you ain’t happy.” We system admins are notoriously poor
communicators. If the problem affects users, you need to communicate
the nature of the problem with them and make sure they are aware that
it has been fixed. If applicable, you should also educate them as to
how to keep the problem from occurring in the future. You should also
communicate with your users’ supervisors and ensure they know that the
problem has been fixed.
Step 7. Document the solution. Finally, you need to document the
solution to your problem. That way, when it occurs again a year or two
down the road, you or other system administrators can quickly identify
the problem and how to fix it.
If you use this methodology, you can learn to be a very effective
troubleshooter as you gain hands-on experience in the real world.
LX0-104 Exam Objectives (T)
Being a good troubleshooter is a key part of being an effective Linux
system administrator. I’ve been teaching new system administrators for
nearly two decades now, and this is one of the hard- est skills for
some to master. Some new admins just seem to have an intrinsic sense
for how to troubleshoot problems; others don’t. The reason for this,
in my opinion, is that troubleshooting is part art form. Just as it’s
difficult for some of us (me included) to learn how to draw, sculpt,
or paint, it’s also difficult for some of us to learn how to
troubleshoot.
However, I’ve noticed that, with a little training and a lot of
practice, most new administrators can eventually learn how to
troubleshoot effectively. There are three keys to doing this:
• Using a solid troubleshooting procedure
• Obtaining a working knowledge of troubleshooting tools
• Gaining a lot of experience troubleshooting problems
The last point is beyond the scope of this book. The only way to gain
troubleshooting experience is to spend a couple of years in the
field. However, we can work with the first two points. In the last
part of this chapter, we’ll focus specifically on troubleshooting
network issues. However, the procedure we will discuss here can be
broadly applied to any system problem.
Network problems can be caused by a wide array of issues, and I can’t
even begin to cover them all here. Instead, I want to focus on using a
standardized process for troubleshooting network issues. By using a
standardized process, you can adapt to, confront, and resolve a broad
range of network problems. The model I’m going to present here is by
no means all-inclusive. You may need to add, remove, or reorganize
steps to match your particular situation. However, I hope it gives you
a good base to start from.
Many new system administrators make a key mistake when they
troubleshoot system or net- work problems. Instead of using a
methodical troubleshooting approach, they go off half-cocked and start
trying to implement fixes before they really know what the problem is.
I call it “shotgun troubleshooting.” The administrator tries one fix
after another, hoping that one of them will repair the problem.
This is a very dangerous practice. I’ve watched system administrators
do this and cause more problems than they solve. Sometimes they even
cause catastrophic problems. Case in point: Several years ago I was
setting up several servers in a network. One of the servers was
misconfigured and was having trouble synchronizing information with
the other systems. While I was trying to figure out the source of the
problem, my coworker (let’s call him Syd) started implementing one fix
after another in shotgun fashion trying to get the server to sync with
the other servers. In the process, he managed to catastrophically mess
up all of them! The actual issue was relatively minor and would have
required only about 20 minutes to fix. Instead, we had to spend the
rest of the day and part of the night reinstalling each server from
scratch and restoring their data.
Instead of using shotgun troubleshooting, you should use a
standardized troubleshooting model. The goal of a troubleshooting
model is to concretely identify the source of the problem before you
start fixing things. I know that sounds simple, but many system
administrators struggle with this concept. Here’s a suggested
troubleshooting model that you can use to develop your own personal
troubleshooting methodology:
Step 1. Gather information. This is a critical step. You need to
determine exactly what has happened. What are the symptoms? Were any
error messages displayed? What did they say? How extensive is the
problem? Is it isolated to a single system, or are many systems
experiencing the same problem?
Step 2. Identify what has changed. In this step, you should identify
what has changed in the system. Has new software been installed? Has
new hardware been installed? Did a user change something? Did you
change something?
Step 3. Create a hypothesis. With the information gathered in the
preceding steps, develop several hypotheses that could explain the
problem. To do this, you may need to do some research. You should
check FAQs and knowledgebases available on the Internet. You should
also consult with peers to validate your hypotheses. Using the
information you gain, narrow your results down to the one or two most
likely causes.
Step 4. Determine the appropriate fix. The next step is to use peers,
FAQs, knowledgebases, and your own experience to identify the steps
needed to fix the problem. As you do this, be sure to identify the
possible ramifications of implementing the fix and account for them.
Many times, the fix may have side effects that are as bad as or worse
than the original problem.
Step 5. Implement the fix. At this point, you’re ready to implement
the fix. Notice that in this troubleshooting model, we did a ton of
research before implementing a fix! Doing so greatly increases the
likelihood of success. After implementing the fix, be sure to verify
that the fix actually repaired the problem and that the issue doesn’t
reappear.
Step 6. Ensure user satisfaction. This is a key mistake made by many
system administrators. I like to teach students the adage “If the user
ain’t happy, you ain’t happy.” We system admins are notoriously poor
communicators. If the problem affects users, you need to communicate
the nature of the problem with them and make sure they are aware that
it has been fixed. If applicable, you should also educate them as to
how to keep the problem from occurring in the future. You should also
communicate with your users’ supervisors and ensure they know that the
problem has been fixed.
Step 7. Document the solution. Finally, you need to document the
solution to your problem. That way, when it occurs again a year or two
down the road, you or other system administrators can quickly identify
the problem and how to fix it.
If you use this methodology, you can learn to be a very effective
troubleshooter as you gain hands-on experience in the real world.
LX0-104 Exam Objectives (T)
Troubleshooting Network I
Troubleshooting Network Problems
Getting your network interface installed is only half the battle. To
enable communications, you need to use a variety of testing and
monitoring tools to make sure the network itself is working properly.
We’ll discuss how to do this in this part of the chapter. We’ll cover
the following topics:
• Using a standardized troubleshooting model
• Using ping
• Using netstat
• Using traceroute
• Using nc
• Using name resolution tools
LX0-104 Exam Objectives (T)
Getting your network interface installed is only half the battle. To
enable communications, you need to use a variety of testing and
monitoring tools to make sure the network itself is working properly.
We’ll discuss how to do this in this part of the chapter. We’ll cover
the following topics:
• Using a standardized troubleshooting model
• Using ping
• Using netstat
• Using traceroute
• Using nc
• Using name resolution tools
LX0-104 Exam Objectives (T)
Tuesday, December 13, 2016
Printing IX
Troubleshooting Printing Issues
Ask any system administrator what type of user complaints they receive
most often and I’ll bet 90 percent of them will list two main issues:
• I can’t log in.
• I can’t print.
To manage Linux systems, you need to be able to troubleshoot a wide
variety of printing issues. Obviously, we don’t have the time or space
to cover all possible printing problems here. Instead, I’m going to
give you some key insights that I have gained over the years
supporting users and their print jobs. My experience is that these
insights will cover 80 to 90 percent of the issues you will encounter.
Let’s take a look:
• Always use the standardized troubleshooting model presented in the
previous chapter. Yes, it applies to printing as well as to
networking. Don’t go off half-cocked trying multiple resolutions
before you have a solid understanding of what is wrong and what the
scope of the problem is. Recall that the model I suggested you use
consists of the following steps:
1. Gather information. This is a critical step. You need to determine
exactly what has happened. What are the symptoms? Were any error
messages displayed? What did they say? How extensive is the problem?
Is it isolated to a single system, or are many systems experiencing
the same problem?
2. Identify what has changed. In this step, you should identify what
has changed in the system. Has new software been installed? Has new
hardware been installed? Did a user change something? Did you change
something?
3. Create a hypothesis. With the information gathered in the preceding
steps, develop several hypotheses that could explain the problem. To
do this, you may need to do some research. You should check FAQs and
knowledgebases available on the Internet. You should also consult with
peers to validate your hypotheses. Using the information you gain,
narrow your results down to the one or two most likely causes.
4. Determine the appropriate fix. The next step is to use peers, FAQs,
knowledgebases, and your own experience to identify the steps needed
to fix the problem. As you do this, be sure to identify the possible
ramifications of implementing the fix and account for them. Many
times, the fix may have side effects that are as bad as or worse than
the original problem.
5. Implement the fix. At this point, you’re ready to implement the
fix. Notice that in this troubleshooting model, we did a ton of
research before implementing a fix! Doing so greatly increases the
likelihood of success. After implementing the fix, be sure to verify
that the fix has actually repaired the problem and that the issue
doesn’t reappear.
6. Ensure user satisfaction.You need to communicate the nature of the problem with users
and make sure they are aware that it has been fixed. You should also
educate them as to how to keep the problem from occurring in the
future. In addition, communicate with your users’ supervisors and
ensure they know that the problem has been fixed.
7. Document the solution. Finally,you need to document thesolution to your problem.
That way, when it occurs again a year or two down the road, you or
other system administrators can quickly identify the problem and how
to fix it.
- Document the flow of print jobs. Where do they originate from? Are
they sent over a network connection, or are they sent locally? How do
they eventually arrive at the printer?
- Check the obvious first:
- Is the printer out of paper? (Yes, this happens all of the time!)
- Is the printer turned on?
- If it’s a networked printer, is it connected to the network?
Is the network up?
- Can you ping the printer from the user’s workstation?
- Did the user select the correct printer when sending the print
job?
This is actually the number-one cause of user printing
problems in my experience. If a user has multiple printers configured,
they may not understand the difference between them or simply not pay
attention to which printer they are sending the job to. When the job
doesn’t show up on their printer, they call you. You’ll likely
discover that they just sent 80 duplicate copies of a 100-page document to
someone else’s printer.
- Has the correct printer driver been configured for the printer?
Using the wrong driver will result in hundreds of pages of gibberish
being sent to the printer.
LX0-104 Exam Objectives (Q)
Ask any system administrator what type of user complaints they receive
most often and I’ll bet 90 percent of them will list two main issues:
• I can’t log in.
• I can’t print.
To manage Linux systems, you need to be able to troubleshoot a wide
variety of printing issues. Obviously, we don’t have the time or space
to cover all possible printing problems here. Instead, I’m going to
give you some key insights that I have gained over the years
supporting users and their print jobs. My experience is that these
insights will cover 80 to 90 percent of the issues you will encounter.
Let’s take a look:
• Always use the standardized troubleshooting model presented in the
previous chapter. Yes, it applies to printing as well as to
networking. Don’t go off half-cocked trying multiple resolutions
before you have a solid understanding of what is wrong and what the
scope of the problem is. Recall that the model I suggested you use
consists of the following steps:
1. Gather information. This is a critical step. You need to determine
exactly what has happened. What are the symptoms? Were any error
messages displayed? What did they say? How extensive is the problem?
Is it isolated to a single system, or are many systems experiencing
the same problem?
2. Identify what has changed. In this step, you should identify what
has changed in the system. Has new software been installed? Has new
hardware been installed? Did a user change something? Did you change
something?
3. Create a hypothesis. With the information gathered in the preceding
steps, develop several hypotheses that could explain the problem. To
do this, you may need to do some research. You should check FAQs and
knowledgebases available on the Internet. You should also consult with
peers to validate your hypotheses. Using the information you gain,
narrow your results down to the one or two most likely causes.
4. Determine the appropriate fix. The next step is to use peers, FAQs,
knowledgebases, and your own experience to identify the steps needed
to fix the problem. As you do this, be sure to identify the possible
ramifications of implementing the fix and account for them. Many
times, the fix may have side effects that are as bad as or worse than
the original problem.
5. Implement the fix. At this point, you’re ready to implement the
fix. Notice that in this troubleshooting model, we did a ton of
research before implementing a fix! Doing so greatly increases the
likelihood of success. After implementing the fix, be sure to verify
that the fix has actually repaired the problem and that the issue
doesn’t reappear.
6. Ensure user satisfaction.You need to communicate the nature of the problem with users
and make sure they are aware that it has been fixed. You should also
educate them as to how to keep the problem from occurring in the
future. In addition, communicate with your users’ supervisors and
ensure they know that the problem has been fixed.
7. Document the solution. Finally,you need to document thesolution to your problem.
That way, when it occurs again a year or two down the road, you or
other system administrators can quickly identify the problem and how
to fix it.
- Document the flow of print jobs. Where do they originate from? Are
they sent over a network connection, or are they sent locally? How do
they eventually arrive at the printer?
- Check the obvious first:
- Is the printer out of paper? (Yes, this happens all of the time!)
- Is the printer turned on?
- If it’s a networked printer, is it connected to the network?
Is the network up?
- Can you ping the printer from the user’s workstation?
- Did the user select the correct printer when sending the print
job?
This is actually the number-one cause of user printing
problems in my experience. If a user has multiple printers configured,
they may not understand the difference between them or simply not pay
attention to which printer they are sending the job to. When the job
doesn’t show up on their printer, they call you. You’ll likely
discover that they just sent 80 duplicate copies of a 100-page document to
someone else’s printer.
- Has the correct printer driver been configured for the printer?
Using the wrong driver will result in hundreds of pages of gibberish
being sent to the printer.
LX0-104 Exam Objectives (Q)
Subscribe to:
Posts (Atom)