By: Bob Hewett user 20 Dec 2016 at 11:13 a.m. CST

7 Responses
Bob Hewett gravatar
I've installed Gluu into a Google Cloud instance running Ubuntu 14.04. I am unable to get it running fully. The vm has 7.5 gigs of memory and 2 CPUs. The install seems to be working, but when I go to https://gluu-sso-1.hebgluu.com it redirects, but gives the folowing error: This gluu-sso-1.hebgluu.com page can’t be found No webpage was found for the web address: https://gluu-sso-1.hebgluu.com/identity/ In my hosts file on the Google Cloud server, I have added the external IP address of the Google Compute Engine server. I tried the internal ip, but it went into a redirect loop. My hosts file entry is the same on both my server and personal machine: 104.198.162.203 gluu-sso-1.hebgluu.com Any help would be appreciated. Not sure what my next step is... Here is the selections I used in the setup.py: ``` hostname sso.hebgluu.com orgName HEB os ubuntu city Austin state TX countryCode US support email bob.hewett@mutualmobile.com tomcat max ram 3072 Admin Pass XXXXXXXX Install oxAuth True Install oxTrust True Install LDAP True Install Apache 2 web server True Install Shibboleth SAML IDP True Install Asimba SAML Proxy True Install CAS True Install oxAuth RP True ``` I tried to follow the steps here to no avail: https://support.gluu.org/customization/3436/gluu-244-not-working-with-openldap-even-with-patched-gluu/ I've attached the log.

By Aliaksandr Samuseu staff 20 Dec 2016 at 11:48 a.m. CST

Aliaksandr Samuseu gravatar
Hi, Bob. Please check our [recommendations for issue's description](https://support.gluu.org/docs/user-guide/how-to-ask/) and [logs doc](https://gluu.org/docs/reference/logs/), and provide more details about your setup and issue. Please also try to re-install it once, and share all options you'll choose when running `setup.py` this time. Best regards, Alex.

By Bob Hewett user 20 Dec 2016 at 4:36 p.m. CST

Bob Hewett gravatar
I updated the question....here's the part of the oxauth.log that is failing on: ``` 2016-12-20 22:11:24,744 WARN [org.xdi.oxauth.model.config.ConfigurationFactory] /opt/tomcat/conf/oxauth-config.jso n (No such file or directory) java.io.FileNotFoundException: /opt/tomcat/conf/oxauth-config.json (No such file or directory) ```

By Aliaksandr Samuseu staff 20 Dec 2016 at 5:10 p.m. CST

Aliaksandr Samuseu gravatar
Thanks, Bob. Regarding this error - it's not guaranteed yet it's the cause, as such entry can appear during normal start up too, usually it means something like "can't find configuration file on disk, loading configuration from LDAP (which is expected behaviour)". So we would need full log file to be sure. Could you do next? 1. Move into container 2. `# service tomcat stop` 3. `# mv /opt/tomcat/logs/wrapper.log /opt/tomcat/logs/wrapper.log.bak` 4. `# service tomcat start` 5. `# tail -F /opt/tomcat/logs/wrapper.log`, wait until it will start up fully (or will fail to do so) 6. If it started successfully at previous step, please also do `# tail -F` for all Apache logs in `/var/log/apache2/` (should be 3 files there), attempting to open login page in your browser each time, and share any records appearing there which will seem related to these your attempts (please purge all cookies related to this Gluu instance's name first in the browser) Then provide us the full new wrapper.log it will re-create + those Apache's logs (you could use [https://pastebin.com](https://pastebin.com) or any file-sharing service). Please also provide output of next commands at the moment when service runs: 1. `# dpkg -l | grep -i gluu-server` (outside of the container) 2. `# hostname` (inside of the container) 3. `# cat /etc/hosts` (inside of the container) 4. `# cat /etc/resolv.conf` (inside of the container) 5. `# netstat -nlpt` (inside of the container) > I tried to follow the steps here to no avail: https://support.gluu.org/customization/3436/gluu-244-not-working-with-openldap-even-with-patched-gluu/ That's hardly your case, it's about a custom build of Gluu 2.4.4 compatible with OpenLDAP directory (which will be used in Gluu CE package starting 3.0.0).

By Aliaksandr Samuseu staff 20 Dec 2016 at 5:16 p.m. CST

Aliaksandr Samuseu gravatar
How to know it's started up successfully: if your tail-ing wrapper.log, you'll see that it will stop throwing endless rows of log entries, or will slowdown significantly. Entries like below will mark the end of startup procedure: ``` INFO | jvm 1 | 2016/12/20 18:29:04 | Dec 20, 2016 6:29:04 PM org.apache.coyote.AbstractProtocol start INFO | jvm 1 | 2016/12/20 18:29:04 | INFO: Starting ProtocolHandler ["http-bio-127.0.0.1-8443"] INFO | jvm 1 | 2016/12/20 18:29:04 | Dec 20, 2016 6:29:04 PM org.apache.coyote.AbstractProtocol start INFO | jvm 1 | 2016/12/20 18:29:04 | INFO: Starting ProtocolHandler ["ajp-bio-127.0.0.1-8009"] INFO | jvm 1 | 2016/12/20 18:29:04 | Dec 20, 2016 6:29:04 PM org.apache.catalina.startup.Catalina start INFO | jvm 1 | 2016/12/20 18:29:04 | INFO: Server startup in 257133 ms ``` If it fails to start, usually there will be a lot of lengthy java error traces which you won't miss.

By Aliaksandr Samuseu staff 20 Dec 2016 at 5:24 p.m. CST

Aliaksandr Samuseu gravatar
Sorry, should have mentioned this too: 1. Please run `# ifconfig` (inside of the container) 2. Your list of `setup.py` properties doesn't show which ip you chose back then. Please run this too `# grep -i -e '^ip=' /install/community-edition-setup/setup.properties.last` (inside of the container) A couple more files (inside the container) which you could share to speed up resolution process: 1. `/opt/tomcat/conf/server.xml` (contains some passwords you may opt to remove) 2. `/etc/apache2/sites-enabled/https_gluu.conf`

By Bob Hewett user 20 Dec 2016 at 6:05 p.m. CST

Bob Hewett gravatar
Well...I uninstalled and reinstalled one more time and now it's working! Not sure what went wrong....

By Aliaksandr Samuseu staff 20 Dec 2016 at 6:14 p.m. CST

Aliaksandr Samuseu gravatar
When it comes to large vendors-offered cloud-hosted VPSes, it's often either ip address/DNS name of the instance was incorrectly specified during `setup.py` phase, or some problems with port forwarding/firewalls - there may be 2 different ip addresses/DNS names in play, like for some external proxy/NAT/LB provided by the vendor, and the one internally used, assigned to this VPS. So it may become tricky to set the whole thing correctly. As a rule of thumb, for ip address you must always choose local (internal) ip of this very VPS, but for the DNS name of the instance you must choose the external one (if it has one). Yet, in `/etc/hosts` you should have this external name mapped to the internal ip address, still.