Unable to access web interface

By: David Tessmann user 15 Mar 2017 at 12:09 p.m. CDT

4 Responses
David Tessmann gravatar
Hello, I'm attempting to install GLUU on RHEL 7.3 and I'm having an issue connecting to the web interface after installation. First, some system details: Hardware: VM on vSphere OS: RHEL 7.3 RAM: 4 GB HD: 40 GB CPU: 2 @ 64 bit The VM system is in our internal datacenter. This is a clean OS install with no other apps running on it. I had no issues running the installation steps. I don't know where setup.py stores the answers to the setup questions, but I selected to install Shibboleth SAML IDP and oxAuth RP along with the defaults. IP address and host name were set to that of the server itself. I also had to open ports 80 and 443 in the RHEL firewall (note: instructions don't state to do this. Perhaps they should for us Linux noobs?) As I stated, the installation went fine. But when I try to go to the Web UI, in firefox I get an error: "The page isn’t redirecting properly." I did notice that entering https://[servername].unt.edu redirects to https://[servername].unt.edu/identity/home?cid=15 and that's where I get the error. Here is the setup.log that I found in /opt/gluu-server-3.0.1/install/community-edition-setup: ``` 15:10:53 03/14/17 Copied /opt/dist/gluu/oxauth-rp.war to /opt/gluu/jetty/oxauth-rp/webapps 15:10:53 03/14/17 Rendering test templates 15:10:53 03/14/17 Rendering templates folder: ./templates/test/ 15:10:53 03/14/17 Rendering test template ./templates/test/oxauth/client/config-oxauth-test-data.properties 15:10:53 03/14/17 Rendering test template ./templates/test/oxauth/data/oxauth-test-data.ldif 15:10:53 03/14/17 Rendering test template ./templates/test/oxauth/server/config-build.properties 15:10:53 03/14/17 Rendering test template ./templates/test/oxauth/server/config-oxauth-test-data.properties 15:10:53 03/14/17 Rendering test template ./templates/test/oxauth/server/config-oxauth-test.properties 15:10:53 03/14/17 Rendering test template ./templates/test/oxauth/server/config-oxauth.properties 15:10:53 03/14/17 Rendering test template ./templates/test/oxtrust/server/config-build.properties 15:10:53 03/14/17 Rendering test template ./templates/test/oxtrust/server/config-oxtrust-test-data.properties 15:10:53 03/14/17 Rendering test template ./templates/test/oxtrust/server/config-oxtrust-test.properties 15:10:53 03/14/17 Rendering test template ./templates/test/oxtrust/server/config-oxtrust.properties 15:10:53 03/14/17 Rendering test template ./templates/test/scim-client/client/config-scim-test.properties 15:10:53 03/14/17 Rendering test template ./templates/test/scim-client/data/01. scim-custom-attributes.ldif 15:10:53 03/14/17 Rendering test template ./templates/test/scim-client/data/02. scim-test-data.ldif 15:10:53 03/14/17 Copied ./static/auth/lib/duo_web.py to /opt/gluu/python/libs 15:10:53 03/14/17 Copied ./static/auth/conf/duo_creds.json to /etc/certs/ 15:10:53 03/14/17 Copied ./static/auth/conf/gplus_client_secrets.json to /etc/certs/ 15:10:53 03/14/17 Copied ./static/auth/conf/super_gluu_creds.json to /etc/certs/ 15:10:53 03/14/17 Copied ./static/auth/conf/cert_creds.json to /etc/certs/ 15:10:53 03/14/17 Copied ./static/auth/conf/otp_configuration.json to /etc/certs/ 15:10:53 03/14/17 Changing ownership 15:10:53 03/14/17 Running: /bin/chown -R root:gluu /etc/certs 15:10:53 03/14/17 Running: /bin/chown -R root:gluu /etc/gluu/conf 15:10:53 03/14/17 Running: /bin/chown -R root:gluu /opt/gluu/python 15:10:53 03/14/17 Running: /bin/chown -R root:gluu /var/ox 15:10:53 03/14/17 Running: /bin/chmod -R 440 /etc/certs 15:10:53 03/14/17 Running: /bin/chmod a+X /etc/certs 15:10:53 03/14/17 Running: /bin/chmod u+w /etc/certs/asimbaIDP.jks 15:10:53 03/14/17 Running: /bin/chown -R jetty:jetty /etc/certs/oxauth-keys.json 15:10:53 03/14/17 Running: /bin/chown -R jetty:jetty /etc/certs/oxauth-keys.jks 15:10:53 03/14/17 Running: /bin/chown -R jetty:jetty /opt/shibboleth-idp 15:10:53 03/14/17 Changing permissions 15:10:53 03/14/17 Running: find /opt -user root -perm 700 -exec chmod 755 {} ; 15:10:53 03/14/17 Running: find /opt -user root -perm 600 -exec chmod 644 {} ; 15:10:53 03/14/17 Running: find /opt -user root -perm 400 -exec chmod 444 {} ; 15:10:53 03/14/17 Running: find /etc/gluu -perm 700 -exec /bin/chmod 755 {} ; 15:10:53 03/14/17 Running: find /etc/gluu -perm 600 -exec /bin/chmod 644 {} ; 15:10:53 03/14/17 Running: find /etc/default -perm 700 -exec /bin/chmod 755 {} ; 15:10:53 03/14/17 Running: find /etc/default -perm 600 -exec /bin/chmod 644 {} ; 15:10:54 03/14/17 Running: /bin/chmod -R 644 /etc/hosts /etc/hostname 15:10:54 03/14/17 Running: find /opt/shibboleth-idp/bin -name *.sh -exec chmod 755 {} ; 15:10:54 03/14/17 Running: /usr/bin/systemctl enable httpd 15:10:54 03/14/17 Running: /usr/bin/systemctl start httpd 15:10:54 03/14/17 Running: /usr/bin/systemctl start memcached.service 15:10:54 03/14/17 Running: /usr/bin/systemctl restart rsyslog.service 15:10:54 03/14/17 Running: /usr/bin/systemctl start solserver.service 15:10:54 03/14/17 Running: /usr/bin/systemctl start oxauth-rp 15:11:02 03/14/17 Run: /usr/bin/systemctl start oxauth-rp with result code: 0 15:11:02 03/14/17 Running: /usr/bin/systemctl start oxauth 15:11:18 03/14/17 Run: /usr/bin/systemctl start oxauth with result code: 0 15:11:18 03/14/17 Running: /usr/bin/systemctl start idp 15:11:55 03/14/17 Run: /usr/bin/systemctl start idp with result code: 0 15:11:55 03/14/17 Running: /usr/bin/systemctl start identity 15:12:27 03/14/17 Run: /usr/bin/systemctl start identity with result code: 0 15:12:27 03/14/17 Saving properties to ./setup.properties.last ``` I found two logs in `/opt/gluu-server-3.0.1/var/log/httpd. error_log` contains the following: ``` [Tue Mar 14 15:10:50.224830 2017] [mpm_prefork:notice] [pid 1734] AH00163: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips configured -- resuming normal operations [Tue Mar 14 15:10:50.224930 2017] [core:notice] [pid 1734] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND' ``` Access_log contains a lot more that would be too big to post here. However, since most of the entries repeat, I'll just post one of each type of entry in it: ``` [IPADDRESS] - - [14/Mar/2017:15:36:24 -0500] "GET /index.html HTTP/1.1" 404 274 "-" "Java/1.8.0_112" [IPADDRESS] - - [14/Mar/2017:15:36:54 -0500] "-" 408 - "-" "-" [IPADDRESS] - - [15/Mar/2017:09:37:24 -0500] "GET /index.html HTTP/1.1" 404 274 "-" "Java/1.8.0_112" [IPADDRESS2] - - [15/Mar/2017:09:37:25 -0500] "GET /identity/home?cid=2 HTTP/1.1" 302 - "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0" [IPADDRESS2] - - [15/Mar/2017:09:37:25 -0500] "GET /identity/login?cid=2 HTTP/1.1" 302 - "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0" ``` Please note that for security reasons, I changed the IP address listed in the logs. [IPADDRESS] is the address of the gluu server and [IPADDRESS2] is the address of the workstation attempting to open the web interface. If you need any other info or logs to help me resolve this issue, please let me know where to find them and/or the commands used to get them.
Rhel72
closed

Answers

By Sahil Arora user 15 Mar 2017 at 5:10 p.m. CDT

Copy
Sahil Arora gravatar
Please check oxtrust and oxauth logs. It should have indication. Also make sure you've correct DNS entry in host file on your RHEL host.

By David Tessmann user 16 Mar 2017 at 9:45 a.m. CDT

Copy
David Tessmann gravatar
Thanks for your response. I actually tried a reinstall from scratch after entering my ticket and that worked. I am able to access the interface now. Not sure what the problem was originally, but for future reference, can you tell me where I can find the oxtrust and oxauth logs? Speaking of logs, I'm going through right now setting up Gluu in a test environment for evaluation and I cannot get SMTP messaging to work (we use O365 for email). Are there logs for that? When I test the connection setup, all I get is an error message that says "failed to connect to SMTP server" with no details. Also, is there any documentation anywhere that explains why Gluu uses its own internal LDAP server and copies data from an external source (AD or another LDAP instance)? What is the advantage of this instead of just connecting to the external source and reading the info it needs? If I am to 'sell' this system to management, I'm going to have to explain why we are needlessly (in their eyes) duplicating our current identity databases.

By Mohib Zico Account Admin 17 Mar 2017 at 12:44 a.m. CDT

Copy
Mohib Zico gravatar
Hi David, >> Speaking of logs, I'm going through right now setting up Gluu in a test environment for evaluation and I cannot get SMTP messaging to work (we use O365 for email). Are there logs for that? When I test the connection setup, all I get is an error message that says "failed to connect to SMTP server" with no details. oxtrust.log >> Also, is there any documentation anywhere that explains why Gluu uses its own internal LDAP server and copies data from an external source (AD or another LDAP instance)? What is the advantage of this instead of just connecting to the external source and reading the info it needs? If I am to 'sell' this system to management, I'm going to have to explain why we are needlessly (in their eyes) duplicating our current identity databases. Good question.. Our target is to make Gluu Server as simple as possible for new users/deployers, that's why we tried to keep everything under one shell as someone can start using Gluu Server right away. In our customer base there are organizations who are using: - 'Cache Refresh' or SCIM: To pull/push user's information from their own AD/LDAP server or their existing IDM system. - Organization who are using their own remote LDAP server to store everything.. not only user's information but also Gluu server's configuration. - Organization who are using their Gluu Server's LDAP as their user's primary datastore. As you can see there are variety of customers out there. Another note... other than User's information, we store configurations, temp tokens and sessions inside LDAP as well; so LDAP is important for us ( However, from next version.. 3.1.0 we are going to use memcached + redis to store sessions ).

By David Tessmann user 20 Mar 2017 at 3:08 p.m. CDT

Copy
David Tessmann gravatar
Thanks for the help

Post an answer