Welcome to the new Linux Foundation Forum!

Ex12.1 Task 3,step 4 Cant access URL after replacing internal IP with public IP

yemisishobowaleyemisishobowale Posts: 11
edited April 2017 in LFS252 Class Forum

After checking 'public access' and copying the link location to a new browser, according to step 4 internal IP address should be replaced with public address (Eth0). I get the errror "This site cant be reached'..

Comments

  • serewiczserewicz Posts: 533

    The two things I would look at for a solution is to ensure the container is shared, and double check your public IP address.

    Using the BUI change to a different location and then back. Does the box remain checked, indicating the container has been shared?

    What IP address did you use? They are generated each time, so there is no way to know which is accurate for sure. I'd be interested to see which IP range is being issued. You can also obscure the final octet, so it would be something like 12.45.104.xxyy.

    Regards,

  • The link pointed to different address. I updated the link to eth0 public IP address 104.239.138.xx. I have since closed the lab after completion of the chapter. I can repeat again if you have an suggested resolution steps.

  • serewiczserewicz Posts: 533

    Hello,

    Shoud you return to the lab in the future I'd be happy to try to troubleshoot the issue. If you run the lab again, and have the same issue, please try the above mentioned steps. It looks like you were using the correct IP address. Perhaps a typo? If you remove an extra character from the URL when replacing the IP address it can lead to issues.

    Regards,

     

  • phineyphiney Posts: 18
    edited May 2017

    my ip is 166.78.174.160 and have successfully logged in the BUI and ssh'd using WSL, so the address is good.

    Internal link when right clicking "link" and tested using lynx

    http://192.168.98.1:8080/v1/AUTH_17bf4a8c6e9b494ebf4a446edbcfcab6/orders

    [[email protected] /(keystone_admin)]# lsof -Pni  | grep LISTEN | grep 8080

    swift-pro  1446      swift    4u  IPv4   24942      0t0  TCP 192.168.98.1:8080 (LISTEN)

    swift-pro  2730      swift    4u  IPv4   24942      0t0  TCP 192.168.98.1:8080 (LISTEN)

    swift-pro  2731      swift    4u  IPv4   24942      0t0  TCP 192.168.98.1:8080 (LISTEN)

    swift-pro  2732      swift    4u  IPv4   24942      0t0  TCP 192.168.98.1:8080 (LISTEN)

    swift-pro  2733      swift    4u  IPv4   24942      0t0  TCP 192.168.98.1:8080 (LISTEN)

    swift-pro  2734      swift    4u  IPv4   24942      0t0  TCP 192.168.98.1:8080 (LISTEN)

    swift-pro  2737      swift    4u  IPv4   24942      0t0  TCP 192.168.98.1:8080 (LISTEN)

    swift-pro  2738      swift    4u  IPv4   24942      0t0  TCP 192.168.98.1:8080 (LISTEN)

    swift-pro  2739      swift    4u  IPv4   24942      0t0  TCP 192.168.98.1:8080 (LISTEN)

    swift is not listening on external address

    edit proxy-server.conf and comment out listen ip

    vi /etc/swift/proxy-server.conf

    #bind_ip = 192.168.98.1

    systemctl --list  | grep swift-pro

    [[email protected] /(keystone_admin)]# systemctl restart openstack-swift-proxy.service

    [[email protected] /(keystone_admin)]# lsof -Pni  | grep LISTEN | grep 8080

    swift-pro  3125      swift    4u  IPv4 1728669      0t0  TCP *:8080 (LISTEN)

    swift-pro  3145      swift    4u  IPv4 1728669      0t0  TCP *:8080 (LISTEN)

    swift-pro  3146      swift    4u  IPv4 1728669      0t0  TCP *:8080 (LISTEN)

    swift-pro  3147      swift    4u  IPv4 1728669      0t0  TCP *:8080 (LISTEN)

    swift-pro  3148      swift    4u  IPv4 1728669      0t0  TCP *:8080 (LISTEN)

    swift-pro  3149      swift    4u  IPv4 1728669      0t0  TCP *:8080 (LISTEN)

    swift-pro  3150      swift    4u  IPv4 1728669      0t0  TCP *:8080 (LISTEN)

    swift-pro  3151      swift    4u  IPv4 1728669      0t0  TCP *:8080 (LISTEN)

    swift-pro  3152      swift    4u  IPv4 1728669      0t0  TCP *:8080 (LISTEN)

    so internal procedures when setting up lab should not set bind address.

    P

  • serewiczserewicz Posts: 533
    edited May 2017

    Thank you for the feedback it is helpful to figure out what is going on. After some testing it would appear that the requests are not making it all the way to the instance itself. I have requested the infrastructure team examine the current firewall to see if a port has been blocked recently or any rules have been changed. 

    From within the instance a netstat -tulpn |grep 8080 shows that swift-proxy is listening to the 192.168.98.1 address. When I upload an object to the container and use elinks from the terminal it does work. But exterior requests seem to fail. This is what elinks look like when I attempt it after creating "testfile":


    [[email protected] ~]$ elinks -dump http://192.168.98.1:8080/v1/AUTH_17bf4a8c6e9b494ebf4a446 edbcfcab6/test12 textfile

    I will update you when I hear back from the infrastructure follks.

    Best regards,

  • serewiczserewicz Posts: 533
    edited May 2017

    As P wrote the issue is which IP address is listening. I had been looking at the issue from the wrong perspective. Updating the errata page until I update the material in general. The steps you will see there will be something like this:


    vim /etc/swift/proxy-server.conf .... bind_ip = 0.0.0.0 ... systemctl restart openstack-swift-proxy.service

    Then you should be able to see the content. Great catch phiney!

    Regards,

Sign In or Register to comment.