Hi Branden,

I see an error about cassandra (though from a week ago?)

[2013-06-09T22:58:48.520Z] ERROR: system/6735 on my.hostname.com: Error
initializing server.
    err: {
      "code": 500,
      "msg": "Error connecting to cassandra"
    }

I restarted cassandra, then restarted nginx, same issue with the redirect
to /unavailable.

thanks.


On Tue, Jun 18, 2013 at 10:24 PM, Branden Visser <mrvis...@gmail.com> wrote:

> Hi Steve,
>
> It would probably be either a firewall issue, or the app server didn't
> start up correctly.
>
> Can you have a look at bootstrap.log and server.log (or whichever is
> configured as the app log in config.js) in the home oae directory and let
> us know if there are any errors?
>
> The output log format is raw JSON, but if you pipe it through bunyan (npm
> install -g bunyan to get the binary), it will give a more useful view.
>
> Thanks,
> Branden
>
>
> On Tue, Jun 18, 2013 at 7:28 AM, Steve Swinsburg <
> steve.swinsb...@gmail.com> wrote:
>
>> Hi Branden,
>>
>> Back on this, I'm still getting the same redirect to /unavailable. This
>> is what I'm now getting in the nginx log.
>>
>> 2013/06/18 07:22:42 [error] 3712#0: *284 connect() failed (111:
>> Connection refused) while connecting to upstream, client: 12.34.56.789,
>> server: admin.hostname.com, request: "GET /api/me HTTP/1.1", upstream: "
>> http://12.34.56.789:2000/api/me";, host: "admin.hostname.com", referrer: "
>> http://admin.hostname.com/unavailable";
>>
>>
>> thanks,
>> Steve
>>
>>
>>
>> On Mon, Jun 10, 2013 at 1:16 PM, Branden Visser <mrvis...@gmail.com>wrote:
>>
>>> Yea those need to be adjusted, they should proxy to your Hilary server
>>> IP(s). The etherpad proxy server settings should proxy to the etherpad
>>> server IP as well.
>>>
>>> In config.js, there is configuration for the etherpad server hosts.
>>> Each one will have an external host (the server_name of the nginx
>>> server block) and internal host (the back-end etherpad server IP), and
>>> nginx will need to proxy all of them -- we use puppet to streamline
>>> this for us. This part of the config is a little ugly, but it's like
>>> this so we can shard the etherpad servers. It's necessary until
>>> etherpad has native clustering support.
>>>
>>> Also, to revisit this line from your previous email because I want to
>>> make sure we're on the same page:
>>>
>>> > I am doing this on a remote VPS so have actual DNS records for the
>>> subdomains admin,tenant1, 0.etherpad etc and they are pointing at my actual
>>> IP address in /etc/hosts.
>>>
>>> If you have actual DNS records for the subdomains then /etc/hosts
>>> shouldn't come into play. /etc/hosts is only needed if you don't have
>>> actual DNS. The HTTP Host header is important because it drives the
>>> tenant selection.
>>>
>>> Let us know how it goes!
>>>
>>> Cheers,
>>> Branden
>>>
>>> On Sun, Jun 9, 2013 at 11:04 PM, Steve Swinsburg
>>> <steve.swinsb...@gmail.com> wrote:
>>> >
>>> > HI Branden,
>>> >
>>> > In the nginx error log I see a bunch of errors which may explain it:
>>> >
>>> > 2013/06/09 22:41:38 [error] 10946#0: *78 connect() failed (111:
>>> Connection refused) while connecting to upstream, client: 12.34.567.890,
>>> server: admin.HOSTNAME, request: "GET /api/ui/skin HTTP/1.1", upstream: "
>>> http://127.0.0.1:2000/api/ui/skin";, host: "admin.HOSTNAME", referrer: "
>>> http://admin.HOSTNAME/unavailable";
>>> >
>>> > How do I resolve that? It appears to be looking at localhost  but in
>>> the nginx.conf I have:
>>> > server_name  admin.HOSTNAME;
>>> >
>>> > Do I also need to adjust this:
>>> > upstream globaladminworkers {
>>> >         server 127.0.0.1:2000;
>>> >         # Add extra app nodes here.
>>> >     }
>>> >
>>> > And also for the tenant workers?
>>> > upstream tenantworkers {
>>> >         server 127.0.0.1:2001;
>>> >         # Add extra app nodes here.
>>> >     }
>>> >
>>> > What about the etherpad server proxy settings?
>>> >
>>> >
>>> > cheers,
>>> > Steve
>>> >
>>> >
>>> > On Mon, Jun 10, 2013 at 12:51 PM, Branden Visser <mrvis...@gmail.com>
>>> wrote:
>>> >>
>>> >> Hi Steve,
>>> >>
>>> >> Normally this would happen if the Nginx front-end can't talk to the
>>> app server. Does the server log report a successful start-up? Note there is
>>> a bootstrap.log file that gets some log lines (receives log entries before
>>> the logging modules is initialized). After that, by default it should go to
>>> stdout, unless you configured something different in config.js .
>>> >>
>>> >> Help that helps,
>>> >> Branden
>>> >>
>>> >>
>>> >> On Sun, Jun 9, 2013 at 10:44 PM, Steve Swinsburg <
>>> steve.swinsb...@gmail.com> wrote:
>>> >>>
>>> >>> Hi,
>>> >>>
>>> >>> I've installed OAE using the instructions here:
>>> >>> https://github.com/sakaiproject/Hilary
>>> >>>
>>> >>> However when I go to admin.xxx I see the Administration UI in the
>>> title bar, then get taken to /unavailable.
>>> >>>
>>> >>> I am doing this on a remote VPS so have actual DNS records for the
>>> subdomains admin,tenant1, 0.etherpad etc and they are pointing at my actual
>>> IP address in /etc/hosts.
>>> >>>
>>> >>> But I can't get past this /unavailable issue.
>>> >>>
>>> >>> Any ideas?
>>> >>>
>>> >>> thanks,
>>> >>> Steve
>>> >>>
>>> >>> _______________________________________________
>>> >>> oae-dev mailing list
>>> >>> oae-dev@collab.sakaiproject.org
>>> >>> http://collab.sakaiproject.org/mailman/listinfo/oae-dev
>>> >>>
>>> >>
>>> >
>>>
>>
>>
>
_______________________________________________
oae-dev mailing list
oae-dev@collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/oae-dev

Reply via email to