I am unable to complete the task as it reviewing is marking my task as failed with the following:
- ‘Apache’ is not reachable on port ‘8086’ on App server 1
Question:
Our monitoring tool has reported an issue in Stratos Datacenter. One of our app servers has an issue, as its Apache service is not reachable on port 8086 (which is the Apache port). The service itself could be down, the firewall could be at fault, or something else could be causing the issue.
Use tools like telnet, netstat, etc. to find and fix the issue. Also make sure Apache is reachable from the jump host without compromising any security settings.
Once fixed, you can test the same using command curl http://stapp01:8086 command from jump host.
Troubleshooting:
In App server 1:
I observed that there was no apache as in httpd service is in stopped state, however sendmail was running and listening on port 8086, causing httpd service to not start. Since the question demanded to run apache on port 8086. I’ve stopped and disabled sendmail service and enabled and started httpd service which worked.
I could see iptables was not allowing inbound traffic to 8086. I’ve fixed that too using:
iptables -I INPUT 5 -p tcp --dport 8086 -j ACCEPT
iptables-save > /etc/sysconfig/iptables
There was no webpage being served in /var/www/html, so I’ve added a simple hello world html file in it, then restarted httpd service.
In Jump Server:
I did a curl which worked.
I can see that curl works, the apache server is reachable over port 8086 from jumpserver. I am pretty sure either i am not doing it the way they expect or there is a bug.
No need to add any content to the Apache web server.
Just confirm if port 8086 is being used by any other process, and the IPTable rules are correctly written to the file.
Restart the server
I identified the cause of the issue after testing it twice. In your command, you added the rule as the 5th entry in the INPUT chain. At that time, the last rule in the INPUT chain was a blanket “reject all TCP traffic.” Because of this, any rule added after that reject rule did not take effect.
cd /opt/apps.git/hooks
sudo chown -R natasha:natasha /opt/apps.git
sudo chown -R natasha:natasha /usr/src/kodekloudrepos/apps
sudo vi post-update
#!/bin/bash
date=$(date +‘%Y-%m-%d’) # Get current date in YYYY-MM-DD format
git --git-dir=/opt/apps.git tag “release-$date” master # Create a release tag with current date
sudo chmod +x post-update
Don’t know. But you keep doing things for the task they’re not asking you to do. Just stick to the task, use sudo to access directories that aren’t accessible to the user you ssh’d in on, and then submit it. That’s what I did and it work. Keep it simple, and it usually works.
