I was able to confirm the certificate by going directly to
https://192-168-100-159.realhostip.com/ in the browser. I wish there was
an easier way to do this. I don't mind the extra step, and the rest of my
tech team will understand how it works but it's going to be a hassle
explaining this procedure to everyone else. I really hope someone can
think of a more elegant alternative to realhostip.com when 4.4 is released.
It will lead to better product adoption.
On Fri, May 16, 2014 at 10:49 AM, Ian Young <iyo...@ratespecial.com> wrote:
> Ok, so the console proxy needed to be restarted in order for the
> consoleproxy.url.domain
> setting to take effect. However, I still can't see the console. In
> Chrome, it just shows a frowning face with no error message (not very
> useful). In Firefox, at least it tells me the certificate is not trusted
> because it is self-signed but it doesn't give me the option to accept it.
>
> It's not an unreasonable expectation to be able to use self-signed SSL
> certificates for an internal site. Is there a setting in CloudStack that
> allows them to be trusted?
>
>
> On Fri, May 16, 2014 at 10:38 AM, Ian Young <iyo...@ratespecial.com>wrote:
>
>> The problem appears to be with the console proxy itself. Here are the
>> ports that are listening on the public interface, according to an nmap TCP
>> scan:
>>
>> PORT STATE SERVICE
>> 80/tcp open http
>> 443/tcp closed https
>>
>> When I logged into the console proxy through the link local address, I
>> checked for processes on port 443 and there are none, so obviously an HTTPS
>> connection can't be made. There is a Java process listening on port 80 but
>> nothing on 443. Is there something in the global settings that will enable
>> HTTPS, or is this a bug?
>>
>> root@v-2-VM:~# netstat -lnp | grep java
>> tcp 0 0 0.0.0.0:8001 0.0.0.0:*
>> LISTEN 3491/java
>> tcp 0 0 0.0.0.0:80 0.0.0.0:*
>> LISTEN 3491/java
>>
>>
>> On Thu, May 15, 2014 at 2:53 PM, Ian Young <iyo...@ratespecial.com>wrote:
>>
>>> I just realized I had to set the consoleproxy.url.domain field to "
>>> realhostip.com" but now when I try to view the console, the browser
>>> says "The server refused the connection." Does that indicate a problem
>>> with the SSL certificate?
>>>
>>> management-server.log:
>>> 2014-05-15 14:43:55,506 DEBUG [c.c.a.t.Request] (catalina-exec-15:null)
>>> Seq 1-90898443: Sending { Cmd , MgmtId: 161342909744, via: 1(
>>> virthost1.lax.ratespecial.com), Ver: v1, Flags: 100011,
>>> [{"com.cloud.agent.api.GetVncPortCommand":{"id":2,"name":"v-2-VM","wait":0}}]
>>> }
>>> 2014-05-15 14:43:55,563 DEBUG [c.c.a.t.Request]
>>> (AgentManager-Handler-5:null) Seq 1-90898443: Processing: { Ans: , MgmtId:
>>> 161342909744, via: 1, Ver: v1, Flags: 10,
>>> [{"com.cloud.agent.api.GetVncPortAnswer":{"address":"192.168.100.6","port":5901,"result":true,"wait":0}}]
>>> }
>>> 2014-05-15 14:43:55,563 DEBUG [c.c.a.t.Request] (catalina-exec-15:null)
>>> Seq 1-90898443: Received: { Ans: , MgmtId: 161342909744, via: 1, Ver: v1,
>>> Flags: 10, { GetVncPortAnswer } }
>>> 2014-05-15 14:43:55,563 DEBUG [c.c.s.ConsoleProxyServlet]
>>> (catalina-exec-15:null) Port info 192.168.100.6
>>> 2014-05-15 14:43:55,563 INFO [c.c.s.ConsoleProxyServlet]
>>> (catalina-exec-15:null) Parse host info returned from executing
>>> GetVNCPortCommand. host info: 192.168.100.6
>>> 2014-05-15 14:43:55,570 DEBUG [c.c.s.ConsoleProxyServlet]
>>> (catalina-exec-15:null) Compose console url:
>>> https://192-168-100-159.realhostip.com/ajax?token=CsPhU4m_R2ZoLIdXOtjo3y3humnQN20wt5fSPjbZOHtRh7nli7tiq0ZiWUuwCVIn7K0vuegv6oMAAq_vDY4Vr_f7jwoVQDkxAE1vmK9oRhy9pvBVlmAdCer6hlVjXQlwL9oJEQO4thhSDg2qeNji02xuxlSmDilVKnd9U9xiHqIV-PgktrKq3J2GT1EpcpTvhsew5COQ1h3j8M9IM8KLZpYA0dDp7TejMmfgSiQI8ifZSh_nNLyyqBzYvl1XWxSaDIrnj7UsP3JKUq74kdY5Pg
>>> 2014-05-15 14:43:55,570 DEBUG [c.c.s.ConsoleProxyServlet]
>>> (catalina-exec-15:null) the console url is ::
>>> <html><title>v-2-VM</title><frameset><frame src="
>>> https://192-168-100-159.realhostip.com/ajax?token=CsPhU4m_R2ZoLIdXOtjo3y3humnQN20wt5fSPjbZOHtRh7nli7tiq0ZiWUuwCVIn7K0vuegv6oMAAq_vDY4Vr_f7jwoVQDkxAE1vmK9oRhy9pvBVlmAdCer6hlVjXQlwL9oJEQO4thhSDg2qeNji02xuxlSmDilVKnd9U9xiHqIV-PgktrKq3J2GT1EpcpTvhsew5COQ1h3j8M9IM8KLZpYA0dDp7TejMmfgSiQI8ifZSh_nNLyyqBzYvl1XWxSaDIrnj7UsP3JKUq74kdY5Pg
>>> "></frame></frameset></html>
>>>
>>> ssl_access_log:
>>> 192.168.100.166 - - [15/May/2014:14:44:55 -0700] "GET
>>> /client/console?cmd=access&vm=086b5822-de00-4764-8b05-d8e00657ee54
>>> HTTP/1.1" 200 405
>>>
>>>
>>> On Wed, May 14, 2014 at 5:56 PM, Ian Young <iyo...@ratespecial.com>wrote:
>>>
>>>> Looks like it's still using HTTP, not HTTPS:
>>>>
>>>> 2014-05-14 17:52:35,812 DEBUG [c.c.a.t.Request] (catalina-exec-20:null)
>>>> Seq 1-800529939: Sending { Cmd , MgmtId: 161342909744, via: 1(
>>>> virthost1.lax.ratespecial.com), Ver: v1, Flags: 100011,
>>>> [{"com.cloud.agent.api.GetVncPortCommand":{"id":6,"name":"i-5-6-VM","wait":0}}]
>>>> }
>>>> 2014-05-14 17:52:35,861 DEBUG [c.c.a.t.Request]
>>>> (AgentManager-Handler-1:null) Seq 1-800529939: Processing: { Ans: ,
>>>> MgmtId: 161342909744, via: 1, Ver: v1, Flags: 10,
>>>> [{"com.cloud.agent.api.GetVncPortAnswer":{"address":"192.168.100.6","port":5903,"result":true,"wait":0}}]
>>>> }
>>>> 2014-05-14 17:52:35,861 DEBUG [c.c.a.t.Request] (catalina-exec-20:null)
>>>> Seq 1-800529939: Received: { Ans: , MgmtId: 161342909744, via: 1, Ver: v1,
>>>> Flags: 10, { GetVncPortAnswer } }
>>>> 2014-05-14 17:52:35,861 DEBUG [c.c.s.ConsoleProxyServlet]
>>>> (catalina-exec-20:null) Port info 192.168.100.6
>>>> 2014-05-14 17:52:35,861 INFO [c.c.s.ConsoleProxyServlet]
>>>> (catalina-exec-20:null) Parse host info returned from executing
>>>> GetVNCPortCommand. host info: 192.168.100.6
>>>> 2014-05-14 17:52:35,865 DEBUG [c.c.s.ConsoleProxyServlet]
>>>> (catalina-exec-20:null) Compose console url:
>>>> http://192.168.100.159/ajax?token=CsPhU4m_R2ZoLIdXOtjo3y3humnQN20wt5fSPjbZOHtRh7nli7tiq0ZiWUuwCVIn_GSECIK5nC2lBX8cMHvt1_GrmwDVK1PEEAwyueLlgNRgodobz8Lsyv2jEc-mUvMH340AYGt0FyZOuXIA6dunN3yx-bP-vp4rao5Up61eJwOvqFr3PhggNpbq5Up59ObOdYMe2GsBP_3FrL8ZQfBhNBSmViHQ0fKJSyUHDoC9tKlfs2Bb0rPOBxsZeTPfe-hDuaVT-pZxjQXCKM93sujnWw
>>>> 2014-05-14 17:52:35,865 DEBUG [c.c.s.ConsoleProxyServlet]
>>>> (catalina-exec-20:null) the console url is ::
>>>> <html><title>phonesynergy</title><frameset><frame src="
>>>> http://192.168.100.159/ajax?token=CsPhU4m_R2ZoLIdXOtjo3y3humnQN20wt5fSPjbZOHtRh7nli7tiq0ZiWUuwCVIn_GSECIK5nC2lBX8cMHvt1_GrmwDVK1PEEAwyueLlgNRgodobz8Lsyv2jEc-mUvMH340AYGt0FyZOuXIA6dunN3yx-bP-vp4rao5Up61eJwOvqFr3PhggNpbq5Up59ObOdYMe2GsBP_3FrL8ZQfBhNBSmViHQ0fKJSyUHDoC9tKlfs2Bb0rPOBxsZeTPfe-hDuaVT-pZxjQXCKM93sujnWw
>>>> "></frame></frameset></html>
>>>>
>>>>
>>>> On Wed, May 14, 2014 at 5:41 PM, Ian Young <iyo...@ratespecial.com>wrote:
>>>>
>>>>> I decided to create my own internal realhostip.com. My DNS servers
>>>>> use PowerDNS, not BIND, so the $GENERATE directive was not an option and I
>>>>> didn't want to have to populate my DNS servers' databases with a record
>>>>> for
>>>>> every possible IP address. Fortunately, I found the following Lua script:
>>>>>
>>>>> https://github.com/terbolous/powerdns-cloudstack-proxy-dns
>>>>>
>>>>> I can confirm the Lua script works as expected and my CloudStack
>>>>> server can be tricked into believing my internal DNS servers are the
>>>>> authority for realhostip.com:
>>>>>
>>>>> [root@virthost1 ]# dig +short 1-2-3-4.realhostip.com
>>>>> 1.2.3.4
>>>>>
>>>>> I followed this guide and updated the console proxy/SSVM SSL
>>>>> certificate with my own *.realhostip.com certificate.
>>>>>
>>>>>
>>>>> http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/systemvm.html#changing-the-console-proxy-ssl-certificate-and-domain
>>>>>
>>>>> The console proxy restarted but it's still blank when I try to view
>>>>> the console. Does the domain have to be something other than
>>>>> realhostip.com?
>>>>>
>>>>
>>>>
>>>
>>
>
