Doug gave me a new problem to troubleshoot that is not related to the problems had with the web server before, so it's likely not related to Apache not running. I got the credentials to SSH into the server and a URL plus a CNAME, which is another alias which is a hostname that points to another hostname. He gave me a few hints that this problem actually comprises two things that need to be discovered and fixed and that there may be network resources such as routers, switches or other servers or something unknown that I will need to use to solve the problem and he gave the premise that the sys admins created a new site, but they cannot figure out why it's not working.
I started by going to both of the websites. Neither of them loaded, both error pages said that the hostnames server IP address could not be found. I ran Windows diagnostics on the connection, my end works fine but there was no response from the site. I ran nslookup on the website.christian.com hostname and got the IP address of 192.168.1.132. I can ping the server. 4 packets sent, received, 0 lost. I ran an nslookup as well as a dig command on the both hostnames and got the information that dragon resolved to 192.168.1.133, not 132. I pinged 133 and it said that the destination host is unreachable.
To fix the DNS discrepancy since it is resolving to 133 instead of 132, I can't just SSH into a machine to fix it, there is no serial RS-232 port to connect to, there is no terminal thing here that is normal procedure. How this is fixed, as Doug explained because I was totally confused, he asked what machine is it on and I said I didn't know. Isn't it running Linux or something? He said it's a Windows machine. And the way we remote access a Windows machine to fix a problem is usually to use the Remote Desktop Protocol.
So I pressed the windows key and typed remote desktop, expanded the options at the bottom of the window, typed the IP address for this scenario which was 192.168.1.100 for the DNS server, entered my student credentials to access the domain (Windows did try to offer credentials for another thing so I needed to change the username back from the other offering by clicking MORE CHOICES and entering just my first name which is my username for the domain, and when the connection was made, this server happens to have the DNS manager in the start menu so I can simply press the windows key and type DNS. DNS Application came up, opened it, an MMC window for the DNS Manager opened. I clicked on the only server listed in the side panel, which expanded to Forward Lookup Zones, Reverse Lookup Zones, Trust Points, and Conditional Forwarders. I clicked on Forward Lookup Zones, then on Christian.com, and a list in the main window appeared with two icons called (same as parent folder) and then an icon called dragon and another called website. I clicked on dragon since it has the IP address discrepancy and sure enough when the Properties window appeared, it showed in Host (A) tab that the IP Address was 192.168.1.133. I changed the last octet to 132, hit APPLY and OKAY and the window closed.
ChatGPT said I needed to flush the DNS and to do this I needed to open a PowerShell window and enter ipconfig /flushdns. It said that the requested operation requires elevation. However, this would be catastrophic. This would delete all the DNS records on the DNS server and now it wouldn't resolve any hostnames to IP addresses.
I did another nslookup and the IP address had in fact changed. No flush needed.
2024-11-13 Wednesday
Okay so I had been talking to Doug last night and he gave me a really big hint that in hindsight I wish he hadn't because it made solving the problem really simple. ChatGPT had given me a series of steps in solving one of the two problems with the server. One of them is now fixed because the IP address for Dragon was the wrong address, 192.168.1.133 and it should have been 132. But one of the problems I face sometimes when going to ChatGPT is it will give you several solutions and you start delving into one and the actual solution is like solution 2 or something. This isn't about not doing that one solution, it's just that I need to understand what the first solution is so I can know what I am doing. And in that process, the next solution sometimes gets lost. So that happened last night but not necessarily because I delved too deep, I actually ended up solving one of the two problems doing this and when going over my work with Doug he happened to see that list as I scrolled through it looking for another thing that helped me find the first actual solution in this scenario. And he suggested I keep going through those solutions because the answer was actually in there.
So starting with that list, ChatGPT first suggested I do sudo ufw status, now I don't know what that means but under it, ChatGPT explained that I needed to ensure 80/tcp and 443/tcp were listed as allowed. MY assumption was that it would show me a bunch of ports so when I went sudo ufw status, it simply said OpenSSH ALLOW Anywhere and on the next line, OpenSSH (v6)ALLOW Anywhere (v6). I went to Doug because I am sitting here like, um, sudo ufw status isn't showing all the ports. Whats the deal and I wish I hadn't have done this, because then he was in so many words like yeah, those are the only open ports. Actually, he said something like asking me what a firewall does by default and I said it stops things, and he said something like the ssh port is open. And I was like, wait, so 80 and 443 are not.
He was willing to go with me on making it hard and so I guess he was busy and forgot to make it hard. I am confident I would have figured it out. My next move if Doug hadn't said anything would have been to tell chatGPT the results and ask why it isn't showing ports 80 and 443 at which point it would have explained somewhere that it was showing all the open ports and I would have realized, oh, ports 80 and 443 are not open.
I was like, so I just solved the problem. He said I identified it, now I need to implement the solution. Okay so I went sudo ufw allow port 80/tcp and sudo ufw allow 443/tcp and it said rule added twice, one for ipv4 and another for 6 after opening 80 and then both rules added again for 443. I reloaded the webpage.
Hahaha, it's not fixed! He wasn't making it easy.
Okay, so if you have a VPN like me you might want to deactivate it, not even a half tunnel. My DNS kept switching to my Pi Hole and then I have another strange DNS problem that keeps resetting my DNS for some reason. A New thing to troubleshoot. But the problem is solved. The main hostname was resolving to the wrong IP address by one wrong digit, and then ports 80 and 443 needed to be opened so HTTP and HTTPS could be used to receive webpage requests and serve them back to the users.
No comments:
Post a Comment