The Method of Troubleshooting

Here thou shalt isolate a single fault by means of one trial, comparing the expected outcome with that which is actual, and choosing thy next course of action. This method may be applied unto a programme, a vessel, or a service of the network. Thou requirest a known user’s act which ought to have succeeded, and access thereto in order to examine the solution at hand.

Beginne ye with the seven steps and “Trial Expected against Actual”, employing them within Task One. The sequence of networking standeth as support when the fault pertaineth unto networks. The table concerning Linux/Proxmox is but an example, not commands thou must execute for every error. The self-examination remaineth optional practice.

If thou wouldst behold this method employed upon a particular flaw, follow [[Feilsokingsmetode Level 2 - Modellert feilsøkning av en app|modelled troubleshooting of an application]]. Therein dost thou justify thine ensuing trial ere thou openest the proposed answer.

The Seven Steps

1. Map out the circumstances. What transpired, and when did it commence?
2. Replicate the error ‘tis safe to so again.
3. Locate and confine the likely sources of fault – which layer or component may be to blame?
4. Gather intelligence – logs, messages of woe, results of commands.
5. Debate possible remedies based upon what thou now knowest.
6. Prove one fix or hypothesis alone. Alter many things in haste, and thou shalt not discern that which truly mended all.
7. Record the flaw and its cure, lest ye forget when next such trouble doth return.

The Order of Troubleshooting for Networks and Services

When thou know’st not where a network error lies, this order shall grant thee a point to begin from. If thou hast already a pertinent test result, employ it to choose whither thou shalt investigate further. ‘Tis no need for thee to run all network tests for a code fault.

flowchart TD
    A[Bodily Coupling] --> B[Network's Boundary Gate]
    B --> C[The IP's Arrangement]
    C --> D[A Local Domain]
    D --> E[Beacon and Routing Paths]
    E --> F[Name Lookups (DNS)]
    F --> G[Serving of Duties]

Vidio: How to Test Network Connection with Ping

The vidio doth shew how the ping may be employed to ascertain if a device is attainable o’er the network.

Upon each point, thou shouldst be able to:

• expound upon what the check-point in truth examineth
• discover pertinent values by means of the right commandment (see [[Protocols Level 1 - Network Protocols|🌐 Network Protocols]] for ping, nslookup and more)
• distinguish an observation from a surmise
• choose the next probe based upon the outcome of the former one, not from gut-feeling

Commandments per Layer in a Linux Virtual Machine within Proxmox

Herein lies the application of this method when a Linux virtual machine doth not reach its intended service. Execute pertinent commands within the Console of said virtual machine, and not within the Shell of the Proxmox host. Behold 🧭 Naviger i Proxmox VE should ye require it. Choose thy test according to that which thou investigatest; the table below is no prerequisite unto Task 1.

Shouldst thou lack the standard route, investigate how the virtual machine ought to attain targets outside its own net; certain destinations may hold their own paths. Some networks do block ping, thus the absence of response proveth not alone that the bond is broken. If name resolution and package sources do function well, then hast thou concrete results wherewith to proceed further. 🌐 IP, subnett og standard gateway expoundeth upon address, prefix, and route.

To prove what is expected against that which transpires

A test of error-hunting shall serve no purpose unless thou know’st thy expectation ere thou dost enact it. Set down thusly:

Requiem:            What mayst thou doeth, O user so blest?
Purpose:            To which address or service dost thou put thy test to rest?
Anticipate:         What shall transpire if all things go well in their quest?
Actual:             What hath befallen thee in this mortal contest?
Doth Shew:          What proof doth this outcome present before thine eyes' best?
Not Sole Proof:     What truth does NOT this result shun from its crest?

Task the First - Apply this Method unto a Real Concern

Takest thou a problem which hath been encountered in another Discipline of Operations or Development (a container that will not commence, a service with whom no contact may be made, a script that doth err):

1. Proceed ye through the seven steps above, one by one.
2. Pen down «expected against actual» for each trial thou dost execute.
3. Record which component or layer the test doth delineate. Employ the network sequence only when it suiteth the issue at hand.
4. Attempt one reasoned correction within a testing environment where change is permitted. Repeat the original user’s action and verify that the amendment truly taketh effect. Retain a path back unto the former configuration.

Shouldst thou have no fault at thy disposal, thou mayest analyze this instance: An application yieldeth the expected page upon /, yet returneth an HTTP 404 upon /status. What do these two responses reveal, and what wouldst thou first examine? Both requests received an HTTP response; the initial inquiry is whether /status doth indeed exist within the app, and if the client useth the correct route. This example serveth as practice in analysis, not proof that thou hast rectified thine own solution.

Check-Pointe: The Fault Is Bounded And In Hand

Show me thy log of tests, and declare which observation didst support the next assay or the remedy thereof. After the amendment is wrought, let that first action yield the fruit it should. Thou mayest set this forth by word of mouth, or in writing with commands and their fruits before thine eyes. If yet the fault stands open, then name what hath been tried, what remains uncertain, and one precise trial to come. Write not a guessed cause as if ‘twere surety proven.

Proove Thine Own Mettle

A voluntary self-assessment with feedback is at thy disposal. Thy answers shall not be conveyed unto thine instructor. Employ thine own log of trials to demonstrate true debugging for aye, lest this self-test supplant the practical inspection thereof.

A Summary of Matters

• The seeking out of faults is a method, no mere guessing it is – seven steadfast steps from discovery unto record-keeping
• By means of the bisection method one may confine a chain when thou knowest the links which thy trial employeth
• Concerning networks: make use of the layers to choose a fitting next assay based upon that which thine eyes hath beheld
• Ever write down that which was hoped against that which came to pass ere thou dost try, and remember well that but seldom doth a single proof confirm all things