Chapter 10 Internet Troubleshooting i-NET+ EXAM OBJECTIVES COVERED IN THIS CHAPTER:  Identify problems related to legacy clients (e.g., TCP/IP sockets and their implication on the operating system). Content could include the following:  Checking revision date, manufacturer/vendor  Troubleshooting and performance issues  Compatibility issues  Version of the Web browser  Explain the function of patches and updates to client software and associated problems. Content could include the following:  Desktop security  Virus protection  Encryption levels  Web browsers  E-mail clients  Describe the process of pre-launch site/application functionality testing. Content could include the following:  Checking hot links  Testing different browsers  Testing to ensure it does not corrupt your e-commerce site  Load testing  Access to the site  Testing with various speed connections Copyright © 2000 SYBEX Inc., Alameda, CA. www.sybex.com  Describe when to use various diagnostic tools for identifying and resolving Internet problems. Content could include the following:  Ping  winipcfg  ipconfig  ARP  Trace Routing Utility  Network Analyzer  Netstat Copyright © 2000 SYBEX Inc., Alameda, CA. www.sybex.com B ugs and errors infest the World Wide Web—expect them to crop up on your Web site. Bugs stop people from using your Web site and can permanently damage your reputation. So, although some bugs are inev- itable, it is important to reduce the number and effect of bugs that sneak into your site. In the preceding chapter, you learned the importance of advance planning for the back and front ends of your Web site. Careful planning will reduce the number of bugs and errors that your users experience, but bug detection and fixing is an ongoing process. In this chapter, you’ll learn about important areas of troubleshooting and debugging:  Fixing bugs before your audience sees them  Resolving Internet problems  Virus protection  Software updates  Legacy clients A clear understanding of these topics will limit the number of bugs you inflict on your users and can lead to quicker resolution of errors that you do find. Copyright © 2000 SYBEX Inc., Alameda, CA. www.sybex.com 456 Chapter 10  Internet Troubleshooting Web Site Pre-Rollout Testing B efore you roll out a new Web site, or change an existing site, you should make sure it has as few bugs as possible. A new site is kept “private” until its launch date. When it is rolled out, everyone is allowed in to try it out. You should only make your site public once you have ironed out most of the bugs. You probably have similar concerns for your existing sites—you don’t want to make your big mistakes in public. Changes to a Web site can make the site unreadable or make Web applications return an error. Web sites are complicated and contain unexpected dependencies—so even changes to one page may break something on a different part of the site. Just as new sites are kept private until they are rolled out, changes to existing sites should be tested in a private area, and then the changes can be installed once they are verified as correct. To “break” a Web site is to make it unusable. There are many ways to break a Web site, most of them unexpected. You might corrupt the graphic layout of a page, make a CGI script stop performing its duties, or even make the server freeze. There are two things you need before you make your site public:  A method for privately testing your changes  A checklist of what problems to look for With a method and checklist in place, you can tinker with your Web site and not be afraid that your changes will break the chairman of the board’s favor- ite page. Develop a Testing Methodology If avoiding errors in your public Web site is important to you, you should use a standard testing methodology . A testing methodology is the set of proce- dures you perform each and every time you make a change. The goal is to check the validity of every page. With a written methodology, you will use the same procedure each time you check your site, reducing the possibility of missing a potential problem through carelessness, sloppy work, or ignorance. Copyright © 2000 SYBEX Inc., Alameda, CA. www.sybex.com Web Site Pre-Rollout Testing 457 Whether your Web site is small or large, a testing methodology decreases the likelihood that you’ll seriously break it. By following a standard proce- dure, you’re less likely to forget to check for whatever broke your site the last time you changed something. As time goes on, you can fine-tune the extent of your testing, depending on how often things break and how effective your testing is in finding errors. In the following sections, we’ll give you an example of a simple test- ing methodology and then discuss some components of a more advanced testing methodology—a location for testing and a storyboard to follow. Later, we’ll review the different types of problems you may discover in a Web site. You can then proceed to develop a testing methodology that fits your needs. Simple Error Checking Different scale Web sites require different scale tests. Joe’s home page proba- bly doesn’t need as much testing as Amazon.com’s home page; the cost of an uncaught bug is significantly smaller for Joe than it is for Amazon.com. Joe could probably get away with a simple testing methodology like the following: 1. Download old page from public Web site. 2. Edit page on local computer. 3. View local page in browser. 4. Upload page to public Web site. 5. View public page in browser to make sure the changes show up. These steps reduce the chance that Joe will break his home page and that the broken page will remain broken until someone e-mails Joe. For example, he’ll know when he performs step 5 if his upload failed. Notice two key points about Joe’s method:  Joe used his hard drive as a private area for development.  Joe double-checked his changes to make sure he didn’t break anything. More advanced checking builds on these two fundamental aspects of Joe’s testing methodology. Copyright © 2000 SYBEX Inc., Alameda, CA. www.sybex.com 458 Chapter 10  Internet Troubleshooting Private Testing Area One component of a good testing methodology is the use of a private testing area. Joe had this component in his methodology—he tried out changes on his hard drive. He could experiment freely without worrying that people would view his rough drafts. Although Joe might be perfectly happy using a hard drive as a development area, this won’t work for all Web sites. More complex Web sites require different types of private areas. If more than one person will be testing a Web page, it needs to be published on a pri- vate site. Once it is on a private site, the testers can collaborate on the page. Depending on your needs, there are a couple of areas where you can try out your changes:  A private area on your main Web server  An entirely separate test server In the following sections, you’ll see the differences between these two testing areas. You’ll also learn about tools for moving your files from your testing area to the main server. Main Web Servers For most Web sites, the best option for a private testing area is in a private section of the main Web server. This is a common choice because it provides a more functional test environment than a stand-alone hard drive but doesn’t require many additional resources. By reusing an existing server, you can also save the cost of an additional server. You will certainly want to consider publishing your changes to a Web server if you have multiple people looking at a site or if you use pages that need to be tested on a server. By publishing to a private section of a server, you can test server functionality before releasing your site to the public. If the pages being edited use CGI scripts, for example, they can’t be easily tested on a hard drive. Staging Servers If you find that the private version of your Web site is interfering with your main site, you may need a staging server. A staging server is a separate Web server on which you can put a private version of your public Web site. It has almost all the functionality of the public Web site, yet it won’t interfere with the public site. Staging servers are useful because tests to it will accurately Copyright © 2000 SYBEX Inc., Alameda, CA. www.sybex.com Web Site Pre-Rollout Testing 459 predict how changes will affect the public site, but tests that corrupt the stag- ing server will not affect the main site. Staging servers are particularly useful if you are experimenting with new versions of an operating system, new databases, or anything that might crash a whole server. If you ever find yourself wondering if your actions on your test site are going to crash the server, you may want to consider getting a staging server. Quality assurance is a job function in which applications are checked to make sure they work as expected. People doing quality assurance report bugs. Copying Files between Servers Whatever the complexity of your testing needs, it should be fairly simple to move files between the private testing area and the main area. If it is too com- plicated, errors can be introduced in the transfer process. HTML editors, such as NetObjects Fusion or Microsoft FrontPage, have publish/export/save as settings that explicitly support uploading development code to multiple serv- ers or to different areas on a single server. These HTML helpers make sure the file location tags are rewritten to accommodate multiple servers. Figures 10.1 and 10.2 demonstrate the capabilities available in many HTML helpers. Figure 10.1 shows the Server Locations tab in the Publish Setup dialog box of NetObjects Fusion. In this dialog box, users can add, edit, or delete server locations. Notice that there are presently three server locations defined: Main Server, My Computer, and Remote Staging Server. Figure 10.2 shows the Publish Site dialog box. Here, the user can select which server to publish to, as well as whether to publish the entire site or only the changed assets. Once you set up the location of each server, it should be easy to try out and debug changes before your audience can find them. Copyright © 2000 SYBEX Inc., Alameda, CA. www.sybex.com 460 Chapter 10  Internet Troubleshooting FIGURE 10.1 Defining multiple servers FIGURE 10.2 Publishing to a staging server Copyright © 2000 SYBEX Inc., Alameda, CA. www.sybex.com Web Site Pre-Rollout Testing 461 Use the Storyboard Another crucial component to any testing methodology is checking to make sure the page does what it is supposed to do. When Joe double-checks the changes to his home page, he can just look at the single new page and see if the changes are correct. If you happen to have a more complex site, it is more difficult to determine if a set of pages works correctly. A common way to ensure that changes are correct is to check the new pages against a compre- hensive description of how the pages should look and function. This descrip- tion is often called a storyboard . A storyboard is a document that describes how the pages should look and function. It lists screen-by-screen how the pages will look and how the user might interact with them. It will often separate the different elements that go into each screen: what text, graphics, animations, and application code should be on each page. Also, it charts out the relationships between the pages, espe- cially what actions occur when users choose each option on each page. People performing quality-assurance checks can follow each path on the storyboard (like a map) and make sure the text, graphics, and applications all behave as expected. They should make sure the new pages have all the functionality called for in the storyboard, as well as look for any bugs. Avoid Corrupting E-Commerce Web Sites Changes to e-commerce Web sites require special care. Bugs in e-commerce sites mean lost money, so it is especially important that these sites don’t suffer from errors. E-commerce Web sites also typically rely on complex interactions between application servers, SQL databases like Microsoft SQL Server and Oracle, and legacy order-fulfillment systems. Whereas updating a normal Web site is much like releasing the new version of a book, updating an e-commerce Web site is like releasing a software upgrade. Changes in the user interface often accompany changes in the software that runs the site and talks to the database, credit card companies, and possibly an order-fulfillment system. Private testing areas for e-commerce Web sites need to be carefully designed by the people who wrote the software for the e-commerce main site. Copyright © 2000 SYBEX Inc., Alameda, CA. www.sybex.com 462 Chapter 10  Internet Troubleshooting In this section, we looked at two key elements you need to have in place in order to properly test your Web site—a private location to test the pages and a storyboard to check the pages against. We haven’t gone over what you should be testing—you need to decide what is important to you. The next section will serve as a pointer to some of the things you may want to put on your checklist. What to Check As quality control testers go through the site, they should look for everything that could appear to be a bug to the target audience. Basically, they ask the following questions:  Do all pages exist?  Do pages appear and function correctly?  Do new pages cause applications to generate error messages or use the wrong logic?  Do pages meet site policies, such as on content types and file size?  Can the server handle the new files? In the following sections, we’ll cover each of these elements in more detail. Once all of these elements have been checked, you can safely roll out your site. Link Checking (Checking Hot Links) Link checking solves a common problem with Web sites: broken hot links. Broken hot links are links that return a “404—File not found” message when you follow them. The server says “File not found” because the links are to files that don’t exist. Link checking is the process of ensuring that all of the files are in place. To check links, follow the site map or storyboard and click every link. If you find a broken link, report it. You should also look for paths that the storyboard or site map indicates should exist yet do not. Nothing beats the human eye, but there are some automated tools that visit every link on the site for you and report broken links and malformed HTML. See tucows.tierranet.com/htmlval95.html for a list of Windows utilities that do this. Copyright © 2000 SYBEX Inc., Alameda, CA. www.sybex.com [...]... for a funny user/sysadmin translation phrase book Troubleshooting Steps When you’re troubleshooting, it’s helpful to follow a procedure so you don’t forget important steps You can follow CompTIA’s Network+ Copyright © 2000 SYBEX Inc., Alameda, CA www.sybex.com 468 Chapter 10 Internet Troubleshooting troubleshooting model, for example, to debug your Internet problems This model has eight steps: 1 Identify... prerollout testing methodology Troubleshooting Tips These eight steps are a good overall methodology for troubleshooting You can bolster this methodology with tips and advice from the following sections Here’s a guide for when to use the tips in the following sections during the model troubleshooting process Copyright © 2000 SYBEX Inc., Alameda, CA www.sybex.com 472 Chapter 10 Internet Troubleshooting Understanding... www.sybex.com 476 Chapter 10 Internet Troubleshooting Connectivity problems often go away if you try again in a minute or two You can see Internet Explorer failing to find the DNS entry for www google.com in Figure 10.7 and then finding the DNS entry and displaying the Web page seconds later in Figure 10.8 FIGURE 10.7 Internet Explorer can’t find the DNS entry FIGURE 10.8 Internet Explorer can find the... and the Internet If a site is inaccessible only to people on certain Internet backbones, there is probably a connectivity problem between the site’s Internet access provider and other backbones In this case, the only thing you can do is report the connectivity problem to the site’s Internet access provider and wait for them to fix the problem User Connectivity Problem If it turns out the entire Internet. .. www.sybex.com 478 Chapter 10 Internet Troubleshooting Some Web server software (e.g., Microsoft IIS) allows you to configure your own error messages to make a Web site more “friendly.” FIGURE 10.9 A Netscape “File not found” error Isolate the Cause of HTTP Errors The first part of step 3 (of the troubleshooting steps discussed earlier) is to determine where on the network an Internet problem occurs The... Inc., Alameda, CA www.sybex.com 474 Chapter 10 Internet Troubleshooting FIGURE 10.5 A Netscape online error message In the following sections, we’ll examine in more detail these three different types of error messages and what they may indicate Browser Functionality Errors Many error messages that the browser generates may have nothing to do with the Internet If a browser recognizes that it is being... from multiple places on the Internet This allows you to get a better sense of where Internet connectivity problems are Server or Server’s Network Is Down If the problem occurs for everyone trying to look at a site, either the server is down or the target site’s network connection is down If you have access to the server, see if it is on and if it has network connectivity to the Internet (see “Network Connectivity... download points This helps them avoid bandwidth and latency problems Copyright © 2000 SYBEX Inc., Alameda, CA www.sybex.com 466 Chapter 10 Internet Troubleshooting FIGURE 10.3 MySQL download mirrors Copyright © 2000 SYBEX Inc., Alameda, CA www.sybex.com Resolving Internet Problems 467 If you are unsure of whether you need to worry about the capacity of your server, keep an eye on your network and server... In the following sections, you’ll learn when to use various diagnostic tools for identifying and resolving Internet problems Specifically, you’ll learn about the following utilities: ARP Netstat Ping winipcfg ipconfig Copyright © 2000 SYBEX Inc., Alameda, CA www.sybex.com 484 Chapter 10 Internet Troubleshooting Trace Routing utility Network analyzer utilities The i-Net+ exam only covers when to use these... is responding Copyright © 2000 SYBEX Inc., Alameda, CA www.sybex.com 486 Chapter 10 Internet Troubleshooting You can use both Ping and tracert to see if you can reach a host You generally will use Ping if you just want to see if the host is responding to you If you also want to see how your packets are routed over the Internet to the host, use tracert The winipcfg and ipconfig Utilities Of all the TCP/IP . Alameda, CA. www.sybex.com 468 Chapter 10  Internet Troubleshooting troubleshooting model, for example, to debug your Internet problems. This model has eight. Chapter 10  Internet Troubleshooting FIGURE 10.3 MySQL download mirrors Copyright © 2000 SYBEX Inc., Alameda, CA. www.sybex.com Resolving Internet Problems