Piszki Lab | EN

My case study in the clouds…

Horizon Workspace: FQDN and SSL certificates in access from the Internet.

| 0 comments

This entry is the result of weekly battles associated with the development of a method that will change the FQDN of the gateway-va, so that we can get to the Horizon Workspace from the Internet. Why is this action rises to the rank of the problem? According to the documentation , all virtual machines included in the Workspace must be configured with the correct DNS records (A / PTR). The gateway-va machine dont need to be configured at the start in the external FQDN, is administered during the initial configuration. Unfortunately, this is so (even in the latest version of the Horizon Workspace 1.8.1) that during the initial configuration of the whole this parameter is ignored and local DNS address is set as FQDN. This is due to the fact that the machine configurator-va must have full access to the gateway-va FQDN (for it is irrelevant whether it is local or Internet domain), otherwise you will not be able to properly configure the gateway-va. Unfortunately, change of the FQDN is not trivial (during the change required full access and a valid PTR ​​record). Fortunately, as I have sometimes written, there are people on the Internet that make life easier. One of them is Andrea Casini, who developed a good method .

To avoid trouble, at the stage of the installation, it is good to prepare a fake DNS record (but this can also be done with an already running system). So in the local DNS server (in my case: pulab.local), create a false main zone (in my case: pulab.pl) addressing local, compatible with reverse domain zone pulab.local. As a result, the gateway-va gain Internet FQDN and will be available in 100% locally. If you perform NAT from web to the local address ,is enough to create a “fake” zone inverted, so that the PTR record existed and was responsible address of the NAT (this is a change to an existing installation, the new better is a false domain).

fqdn1

fqdn2

After achieving this success (and initial configuration of the total), proceed according to the second method. In the configurator-va add certificates in accordance with the domain name. In the next step we remove the fake DNS record (workspace.pulab.pl) and in its place introduce local record (ughog1.pulab.local) with a valid PTR ​​(very important!). Then restart the gateway-va, during the restart change the server name to be compatible with the DNS record (no need to manually change using the YaST). After logging into the configurator-va we can see it (if you do not see it, you must restart the entire vApp):

fqdn3

That is a total success! This is because the FQDN is different from the name of the host (gateway-va), the Horizon Workspace assumes that it is behind the Load Balancer! If you plan to use more gateway-va, generation of next gateway-va machines is best to start at this time. At the end of a general note, Horizon Workspace is completely dependent on the proper DNS records. Lack of even one PTR crashes whole. The analysis of errors Horizon Workspace is best to start by checking whether the DNS is all OK. In the next post we will be balancing traffic between two gateway-va using the F5 BIG-IP Uśmiech

Was this information is helpful? Tell me, please leave a comment!

Source

Rate this article:
[Total: 0 Average: 0]

Author: Piotr Pisz

Computer always, since I got a Commodore 64 at the end of primary school, through his beloved Amiga and Linux infinite number of consoles, until today, fully virtual day. Since 2001, Unix/Linux Systems Administrator, for seven years a faithful companion and protector of Solaris system, until his sad end. In the year 2011 came in the depths of virtualization, then smoothly ascended into the clouds and continues there today. Professionally working as Systems Architect in the Polish Security Printing Works.

Leave a Reply

Required fields are marked *.


.

Enjoyed the post? Support Piszki Lab | EN, click on the AD! :-)

.