Tag: IP address

Have you missed me? I think my blog site is back. Let me explain…

Loading

On Thursday (13Feb2025) my broadband connection was upgraded from copper wire to full fibre, but it could not be tested, because my router was not compatible.

I reconfigured my router to temporarily go back to my copper wire connection, but, even though my internet service provider (ISP) had agreed to send me a suitable router, they still shut down that line, because the full fibre installation had been completed.

The new router arrived at breakfast time on Friday (14Feb2025), but we did not hear the doorbell, because it relies on WiFi, which had been disabled! Only a chance look out of the window revealed a very patient postman! A very stressful hour followed while I configured the new router ready to restart the blog server, reinstated the internet and WiFi connections, and connect the new web phone, as I needed to work on a client’s server that day. Later in the day my ISP sent me a message that my router was on its way to me!?

My ISP’s support teams are very friendly and helpful, but I am certain they would be less busy if they completed tasks correctly at the first attempt! Friday afternoon was punctuated with online chat discussions with them about access to their business portal to update the web phone settings, which have now been resolved.

My penultimate discussion with my ISP resulted from some access issues to the blog server. In order to assign a web address to the server’s IP address it has to be static, which had been ordered as part of the upgrade package. Mid-afternoon the web address stopped working, which suggested the IP address I had assigned to the web address was dynamic, rather than static. I assigned the new IP address to the web address and, so far, it has not changed again, but my ISP has not yet confirmed that it is now static, which is why I said that I think my blog site is back.

Finally on Monday (17Feb2025) I had a very fruitful conversation with my ISP’s Tech Support, who understood me immediately and finally set my IP address to a static IP address, which worked after I had rebooted my router. This was a revelation, as my previous contacts with Tech Support had been convoluted and ultimately unsuccessful. Therefore, I have spent the day rooting out the occurrences of the old IP address from my WordPress configuration. I am hoping that members of this blog will now be able to interact with it again!

Recommendation: If you have a working server connected to a specific static IP address, DO NOT change it!!

Non-SAS Debugging That Uses My Preferred SAS Debugging Techniques

Loading

The morale of this story is that, once you have proved all the likely reasons for the failure are incorrect, the only remaining reason, however improbable, is the cause!

Note that, as you are reading this post, the problem described below has definitely been resolved!

Over the last few weeks I have been trying to configure my new Linux server to include RAID1 (mirrored) drives, but, while it should only have caused brief service outages for reboots, some of the down times have been rather too long. I have now decided to implement regular copies of the drives instead.

The most recent outage was somewhat baffling, as my attempt to include the RAID1 drives had failed again, but I’d followed my well-practised back out procedure. Unfortunately the server hardware appeared to be up and running, I could access both servers on the device using local IP addresses, but only one, the Apache server and not the WordPress server, using the hollandnumerics.org.uk web address.

A systematic approach to resolving the problem would be needed:

  1. Check the server monitors to make sure the software was running:
    • Both servers were running.
      • The problem was not a failure to start the server software on reboot.
  2. Open the web pages for each server using their local IP addresses:
    • The web pages for both servers opened.
      • Both servers were up and accepting connections.
  3. Open the web pages for each server using their web addresses:
    • The Apache server pages opened, but the WordPress server pages timed out.
      • Maybe a problem with the WordPress port?
  4. Check the WordPress server access log for my attempts to open web pages:
    • Only local addresses were recorded as connecting to WordPress.
      • Maybe a problem with the WordPress port in the router?
  5. Check the event log on the router:
    • All connections to the WordPress port are being blocked.
      • Maybe a fault in the Port Forwarding configuration in the router?
  6. Check the Port Forwarding configuration in the router:
    • All expected entries present.
      • Maybe a fault has developed in the supplied entry used with the WordPress port?
  7. Replace the supplied WordPress entry with a user-modified copy of the working Apache entry, and then open web pages for the WordPress server using their web addresses:
    • The web pages for the WordPress server opened successfully.
      • Problem resolved!

The key actions used to resolve this problem have much in common with those actions listed in my post “How Do You Successfully Debug Your Program?“:

  • Work through the problem testing systematically:
    • Make changes one at a time to be certain you know which one fixes the problem, and also allows you to back out the update if it doesn’t.
    • Test after each change.
    • Review the results from every test.
  • Consider the likely and the unlikely causes of the problem.
  • Most importantly: Read the logs!