Lab 3.2

bike2wrk

Hi,

I am unable to complete Lab 3.2 step #6, access the BUI.  I completed the workaround steps listed in the Lab 2 discussion however I am still unable to connect.  Are we still waiting for Labs 3 & 4 to be fixed by the infrastructure team?

Thanks,

Christopher

phiney

I completed this only two days ago and it was successful. Click quit and start the lab again ?

I did not need to use and workarounds.

Peter

serewicz

Christopher,

These steps were tested and worked since the roll-out of the new lab environment.  Not to say that a new issue could not have happened since then. What is the issue you are finding? Is it a particular error or other situation that may help with the troubleshooting?

bike2wrk

I may be experiencing another user error however I am still unable to login.  After the script (stack.sh) finishes running I try to use the IP address of my host to access the BUI, 192.168.97.2 .  The error I receive in my browser is "This site can't be reached."  I am also unable to ping the IP address of my host from my workstation.  

I found the following warnings in the stack.sh.log but not sure if they are preventing me from reaching the BUI

2017-05-03 18:10:17.805 | /tmp/tmpYAEmlH/pip.zip/pip/_vendor/requests/packages/urllib3/util/ssl_.py:318: SNIMissingWarning: An HTTPS request has been made

, but the SNI (Subject Name Indication) extension to TLS is not available on this platform. This may cause the server to present an incorrect TLS certific

ate, which can cause validation failures. You can upgrade to a newer version of Python to solve this. For more information, see https://urllib3.readthedoc

s.io/en/latest/security.html#snimissingwarning.

2017-05-03 18:10:17.805 | /tmp/tmpYAEmlH/pip.zip/pip/_vendor/requests/packages/urllib3/util/ssl_.py:122: InsecurePlatformWarning: A true SSLContext object

 is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. You can upgrade to a newer vers

ion of Python to solve this. For more information, see https://urllib3.readthedocs.io/en/latest/security.html#insecureplatformwarning.

Do you have any recommendations?

Thanks,

Christopher

 

serewicz

Hello Christopher,

There are two things to look at:

First: It would seem you are using the internal IP address to gain access instead of the public IP address. The 192.168.0.0 address range is protected and does not work across the Internet. If there is no exit trap statement in the ./stack.sh logs then chances are the horizon system is working, but you are not requesting the proper IP.

If you were to look at the output of the ip a command you should find your public IP address under fhe eth0 interface as seen in this example I have just run in the labs: 192.237.213.211  (your public IP will be different)

ubuntu@devstack-cc:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN grou
p default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast sta
te UP group default qlen 1000
    link/ether bc:76:4e:04:c0:77 brd ff:ff:ff:ff:ff:ff
    inet 192.237.213.211/24 brd 192.237.213.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2001:4800:7813:516:be76:4eff:fe04:c077/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::be76:4eff:fe04:c077/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast sta
te UP group default qlen 1000
    link/ether bc:76:4e:04:c0:cd brd ff:ff:ff:ff:ff:ff
    inet 10.100.32.14/20 brd 10.100.47.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::be76:4eff:fe04:c0cd/64 scope link
       valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast sta
te UP group default qlen 1000
    link/ether bc:76:4e:04:c0:70 brd ff:ff:ff:ff:ff:ff
    inet 192.168.97.1/24 brd 192.168.97.255 scope global eth2
       valid_lft forever preferred_lft forever
    inet6 fe80::be76:4eff:fe04:c070/64 scope link
       valid_lft forever preferred_lft forever

 

Second: I'm unsure which lab you are having this issue with. I would guess from the 192.168.97.2 ip address you used that you are on the compute-node system right after adding it to the cloud..   If you have just run the ./stack.sh script on this node to join the cluster, the services running on compute-node would depend on what was enabled in the local.conf.   The example local.conf file we use in the book for the compute-node does not load horizon on the compute-node. It only enables enough for nova to spawn instances and use storage.   Please go to the public address (again eth0) of your devstack-cc node and try to find the horizon BUI at the its public IP address.

If either of these does not work please reply with the entire output of your ip a command and we can try to troubleshoot further.

Regards,

 

bike2wrk

Thanks for responding.  Sadly I did not properly follow the directions. 

On your local system open a browser and point it at the public IP Address of your devstack-cc node. 

I was trying to use the public IP Address of the compute-node.  

Thank you,

Christopher

serewicz

Glad to hear it's working. Thanks for letting us know.

Regards,

fouronthebeach

LFS252 Labs -> cannot access Horizon dashboard in Lab# 2 Task# 5:



ubuntu@devstack-cc:~/devstack$ ip a s eth0

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

    inet 166.78.156.39/24 brd 166.78.156.255 scope global eth0



trying Horizon Dashboard:

http://166.78.156.39/dashboard/auth/login/?next=/dashboard/ -> Not Found



http://166.78.156.39 -> gives Apache page (so Apache appears to be running on the devstack node, just not Horizon.?..)

 

- what am I missing?