Linux System Administration Recipes A Problem-Solution Approach

CHAPTER 1 ■ SAVING YOURSELF EFFORTbe as small and as straightforward/limited as possible while still exhibiting the problem. This too is away of narrowing down the problem before you start.For example, let’s say that a user, Angela, complains that she can’t print from Firefox. Before youstart looking at potential causes, you should run some or all of these tests:• Try printing from Firefox from your own machine.• Try printing from Firefox from Angela’s machine, logged in as yourself.• Try printing from Firefox from Angela’s machine, logged in as her.• If both of these fail, try printing from Firefox from Angela’s machine, logged in asroot. (If you can print from her machine as you or as root, then you may belooking at a user-specific problem rather than a Firefox or printer problem.)• Try printing from the command line on Angela’s machine. (Again, you can try thisas yourself, as Angela, and as root, depending on what results you’re getting.)• While you’re doing the previous tests, make sure that you’re always printing to thesame printer. Then, try some or all of the previous tests but print to a differentprinter.Change only one thing at a time when you’re implementing new features or bug fixing, and test afterevery stage. It’s much easier in the long run to do it this way than it is to have to go back and untangleexactly what you did when and which bit is failing, even if it seems irritatingly slow at the time. (Also, itgives you a nice motivational warm glow of satisfaction when a particular test passes, which is arguablyworth it in itself and cheaper than the warm glow of satisfaction you get from eating a motivational barof chocolate, if less tasty.)So, in our printing problem example, if you log onto the CUPS console (at http://localhost:631)and make a change to one of the printer settings (for example, to the default paper size), run theappropriate tests from your initial setup again before you change anything else. In particular, rerun thetests before you try restarting the printer; it’s very useful to know whether you just need to change thesetting or whether you need to restart the printer for the change to be applied.Not only that, but make sure the change really has been applied (refresh the CUPS console page, inour example) and that you’re testing the right machine (are you sure you’re in the right terminalwindow?) and test again. Then you can change something else. This is along the same lines as beingcareful to make comprehensive initial tests. Change one thing at a time whenever you’re testing so thatyou can be clear on what changes have an effect on the problem.And of course, you should make sure you keep notes while you’re doing it, as per the earlierdiscussions about documentation in recipes 1-1 through 1-4.Another example of good testing practice is to test against either a known-good machine (when bugfixing) or a known-unchanged machine (when implementing something new). Make sure that whateveryou’re testing on the machine you’re working on checks out correctly on the comparison machine. Ifyou’re chasing down a bug and test A fails on both your buggy machine and your comparison machine,then either you’ve discovered a bug of wider scope than you thought or you’re not testing the right thing.Either way, it indicates that you need to rethink. So, in the printing case, if you find that you can printfrom Firefox on your own machine, whoever you’re logged in as, but can’t print from the command line(but not vice versa), then the comparison between this and Angela’s machine will tell you somethinguseful.17Download at WoweBook.Com