By: Matthew Ouille user 27 Apr 2016 at 1:58 a.m. CDT

49 Responses

My web interface is not coming up after a successful installation. This is on a completely clean server. I did see this in the Apache error.log ``` [Mon Oct 06 21:03:38.984205 2014] [unique_id:alert] [pid 10635:tid 140070469556096] (EAI 2)Name or service not known: AH01564: unable to find IPv4 address of "GluuTestUbuntu" AH00016: Configuration Failed [Mon Oct 06 21:33:40.613126 2014] [ssl:warn] [pid 16237:tid 140250090203008] AH01909: RSA certificate configured for 127.0.0.1:443 does NOT include an ID which matches the server name [Mon Oct 06 21:33:40.663646 2014] [unique_id:alert] [pid 16237:tid 140250090203008] (EAI 2)Name or service not known: AH01564: unable to find IPv4 address of "GluuTestUbuntu" AH00016: Configuration Failed [Mon Oct 06 21:34:44.284312 2014] [ssl:warn] [pid 16355:tid 139930760378240] AH01909: RSA certificate configured for 127.0.0.1:443 does NOT include an ID which matches the server name [Mon Oct 06 21:34:44.299808 2014] [unique_id:alert] [pid 16355:tid 139930760378240] (EAI 2)Name or service not known: AH01564: unable to find IPv4 address of "GluuTestUbuntu" AH00016: Configuration Failed ``` I'm not sure what's going on here. I followed the instructions in the wiki pretty much to a T and it didn't come up.

None

closed

By Mohib Zico staff 27 Apr 2016 at 2:02 a.m. CDT

Copy

Seems like something is wrong with hostname you chose during installation. Please use something like 'matthew@test.org' instead of one word hostname.

By Matthew Ouille user 27 Apr 2016 at 2:03 a.m. CDT

Copy

I actually used our full fqdn for the host OS. Should they be different? **EDIT** Just to clarify: I did not ever input _GluuTestUbuntu_ nor do I see where it is

By Mohib Zico staff 27 Apr 2016 at 2:11 a.m. CDT

Copy

Yes.... seems like the hostname you used isn't sufficient enough to generate SSL keys and few other configurations and that's why it's failing.

By Matthew Ouille user 27 Apr 2016 at 2:13 a.m. CDT

Copy

Okay, I had used setup.py so maybe there's an error? Again, I used our actual FQDN for the host server. Not GluuTestUbuntu. I'm in the process of regenerating the http cert and keys.

By Matthew Ouille user 27 Apr 2016 at 2:23 a.m. CDT

Copy

I actually just noticed the dates on this. Is gluu 2.4.3 not stable? It doesn't seem to be. It looks like it's shipping with some really old logs in it and nothing seems to work. Maybe I should try 2.4.2?

By Matthew Ouille user 27 Apr 2016 at 2:35 a.m. CDT

Copy

I just tried 2.4.2 as well and it's still not working. This is extremely frustrating. Does anyone know of what might be causing this on Ubuntu 14.04?

By Mohib Zico staff 27 Apr 2016 at 4:25 a.m. CDT

Copy

Correct. The problem you are facing is with your hostname and/or IP address. It wont' resolve until that issue is fixed. Feel free to browse other Installation related tickets, couple of deployers already faced such issue before. Also don't forget to check the video of [Ubuntu Installation](https://www.youtube.com/watch?v=MqzrLY49vp0) as well.

By Aliaksandr Samuseu staff 27 Apr 2016 at 6:45 a.m. CDT

Copy

Hi, Matthew. Could you provide us contents of `/etc/resolv.conf`, `/etc/hosts` and `/etc/apache2/sites-enabled/https_gluu.conf` files **from within the Gluu's container**, at the time this issue happens? The last one will be too big to post it there, please use [pastebin](http://pastebin.com/) for this one. Regards, Alex.

By Matthew Ouille user 27 Apr 2016 at 11:19 a.m. CDT

Copy

**/etc/resolv.conf** ``` # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 8.8.8.8 nameserver 8.8.4.4 ``` **/etc/hosts** ``` 127.0.0.1 localhost ::1 ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters 45.33.15.53 s14.sdlbk.net ``` ** Apache Config File** [http://pastebin.com/Qsz86MBp](http://pastebin.com/Qsz86MBp) It should also be noted I am using Linode, and I do have access to a private IP address.

By Aliaksandr Samuseu staff 27 Apr 2016 at 11:26 a.m. CDT

Copy

Could you also run `# hostname` from within the container and provide us output? Update: And also run `# openssl x509 -in /etc/certs/httpd.crt -fingerprint -text -noout` from there

By Matthew Ouille user 27 Apr 2016 at 11:27 a.m. CDT

Copy

``` GLUU.root@s14:~# hostname s14.sdlbk.net ```

By Aliaksandr Samuseu staff 27 Apr 2016 at 11:32 a.m. CDT

Copy

> I am using Linode, and I do have access to a private IP address Sorry, not sure how to interpret it. Could you also run `# ifconfig -a` from within the container? We need to be sure that ip address "45.33.15.53" is indeed directly assigned to some interface on that host

By Matthew Ouille user 27 Apr 2016 at 11:34 a.m. CDT

Copy

``` dummy0 Link encap:Ethernet HWaddr a2:f7:67:e7:d0:49 BROADCAST NOARP MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) eth0 Link encap:Ethernet HWaddr f2:3c:91:f1:d7:83 inet addr:45.33.15.53 Bcast:45.33.15.255 Mask:255.255.255.0 inet6 addr: 2600:3c00::f03c:91ff:fef1:d783/64 Scope:Global inet6 addr: fe80::f03c:91ff:fef1:d783/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:132912 errors:0 dropped:0 overruns:0 frame:0 TX packets:119523 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1385288621 (1.3 GB) TX bytes:9656083 (9.6 MB) gre0 Link encap:UNSPEC HWaddr 00-00-00-00-33-63-3A-39-00-00-00-00-00-00-00-00 NOARP MTU:1476 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) gretap0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 BROADCAST MULTICAST MTU:1462 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) ip6_vti0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 NOARP MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) ip6gre0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 NOARP MTU:1448 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) ip6tnl0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 NOARP MTU:1452 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) ip_vti0 Link encap:IPIP Tunnel HWaddr NOARP MTU:1428 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:149333 errors:0 dropped:0 overruns:0 frame:0 TX packets:149333 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:42247099 (42.2 MB) TX bytes:42247099 (42.2 MB) sit0 Link encap:IPv6-in-IPv4 NOARP MTU:1480 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) teql0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 NOARP MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) tunl0 Link encap:IPIP Tunnel HWaddr NOARP MTU:1480 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) ```

By Aliaksandr Samuseu staff 27 Apr 2016 at 11:40 a.m. CDT

Copy

Thanks. What about `# openssl x509 -in /etc/certs/httpd.crt -fingerprint -text -noout` from the container?

By Matthew Ouille user 27 Apr 2016 at 11:42 a.m. CDT

Copy

``` SHA1 Fingerprint=37:58:D6:13:85:5F:9D:88:42:47:C7:8F:A4:0A:54:D8:A1:F5:B4:48 Certificate: Data: Version: 1 (0x0) Serial Number: 11980832212303911977 (0xa644776b7fee9c29) Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, ST=TX, L=Fort Worth, O=Saddleback Leather Co, CN=s14.sdlbk.net/emailAddress=systems@saddlebackleather.com Validity Not Before: Apr 27 07:31:29 2016 GMT Not After : Apr 27 07:31:29 2017 GMT Subject: C=US, ST=TX, L=Fort Worth, O=Saddleback Leather Co, CN=s14.sdlbk.net/emailAddress=systems@saddlebackleather.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:d0:da:c5:03:b7:cf:d1:f8:86:5b:ae:58:5a:c2: 92:79:56:9e:e1:49:aa:dc:2b:77:33:98:64:18:f1: 54:dc:97:f1:97:b3:d8:b6:e6:ce:c3:a8:fc:c7:18: e0:c5:b1:ee:ec:fc:85:d2:e6:ff:c0:1c:d8:01:9b: 6e:c2:51:1e:21:16:6a:ef:c6:47:21:1b:e7:c4:2a: ab:e9:ee:31:b8:a0:6a:87:f5:c9:36:f3:10:8c:21: e5:39:93:16:77:c8:9c:7a:45:88:99:16:2a:3e:9e: 33:36:e1:41:6f:35:95:da:cf:8d:32:49:df:17:99: 13:1b:23:d9:db:bd:84:e6:92:00:64:03:66:b3:62: 0e:81:6a:12:11:0e:06:fe:a9:6d:8e:e1:fd:38:df: 50:d8:48:ab:31:6e:c9:8f:ac:28:fb:e5:5d:aa:77: 04:e9:12:07:9f:c9:37:ab:6f:64:8a:11:dc:4b:84: 5b:7e:c1:8f:10:7d:ab:d1:71:a5:01:c1:ac:14:b0: 1f:cd:f3:14:dd:62:10:6c:90:11:4d:2d:b1:bf:b9: 3e:57:17:5a:98:88:98:59:e3:2e:c0:d2:98:92:ef: ac:ce:36:06:ae:06:23:a6:0c:60:9b:67:68:3a:04: de:26:a2:ec:56:13:85:36:f2:e3:fe:f8:cd:32:eb: 97:dd Exponent: 65537 (0x10001) Signature Algorithm: sha256WithRSAEncryption 6c:09:c8:4c:65:83:59:7c:10:28:4c:e1:91:52:9e:3a:ed:e7: df:d2:fa:97:39:cc:05:47:31:dd:17:3c:fa:9f:fb:13:86:ef: c1:a3:fb:10:29:ab:e0:ce:b1:c3:69:1b:59:64:2f:93:71:c1: c0:dd:19:55:6e:7a:c9:f2:9f:ac:1a:b2:61:13:85:3c:82:b8: 31:de:71:d5:c1:62:9d:b7:4a:7e:65:44:57:20:2d:fd:32:31: ce:c2:2f:17:b2:8d:b5:0a:0e:57:6e:ed:68:76:3c:4a:9d:61: 1c:8e:c4:79:d7:02:39:ac:13:e6:a0:3a:da:ee:8f:04:dd:b6: 15:08:ab:ee:a0:d2:4f:12:5f:d2:81:75:f6:61:14:54:3f:30: 34:76:ac:77:df:f2:da:cc:d1:4b:95:db:c3:17:7f:89:b1:11: dd:b0:74:23:61:82:db:10:51:4f:55:6b:08:e3:c7:7e:f7:25: 27:0a:78:93:fa:75:03:8e:28:2d:43:f0:94:ea:6b:90:af:b7: c7:5b:0f:12:be:89:a6:d0:2e:49:59:99:9b:64:c2:94:f2:ee: 6d:ad:fa:a3:2d:83:89:df:c0:f6:c7:38:69:10:84:f4:68:02: fd:2a:16:77:b7:28:ff:14:c8:51:cf:71:41:e9:9d:41:86:6b: 22:b7:69:93 ```

By Aliaksandr Samuseu staff 27 Apr 2016 at 11:55 a.m. CDT

Copy

I can't see anything wrong yet.. Could you also give us next information (mb we'll be able to reproduce it); run all commands outside of the container: 1. Your distro's full version `# cat /etc/*release` 2. Your Gluu's package full version `# dpkg-query -W | grep -i 'gluu-server-2.4.3'` And if you still keep seeing references to that "GluuTestUbuntu" in logs, could you run one more command, now from within container again: `# grep -I -i -r -e '.*GluuTestUbuntu.*' /opt/`, and give us results?

By Aliaksandr Samuseu staff 27 Apr 2016 at 11:58 a.m. CDT

Copy

Or, even better, let's do `# grep -I -i -r -e '.*GluuTestUbuntu.*' /`

By Matthew Ouille user 27 Apr 2016 at 11:58 a.m. CDT

Copy

``` cat /etc/*release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=14.04 DISTRIB_CODENAME=trusty DISTRIB_DESCRIPTION="Ubuntu 14.04.4 LTS" NAME="Ubuntu" VERSION="14.04.4 LTS, Trusty Tahr" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 14.04.4 LTS" VERSION_ID="14.04" HOME_URL="http://www.ubuntu.com/" SUPPORT_URL="http://help.ubuntu.com/" BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/" ``` I installed 2.4.2 last night because 2.4.3 wasn't working, but nothing else has changed. Yes, there was a clean removal done. ``` root@s14:~# dpkg-query -W | grep -i 'gluu-server-2.4.2' gluu-server-2.4.2 1-1 ``` As I said last night, I think those are old logs that are shipping with the server. They're from the apache error log. I think if you do a fresh install you'll see them as well. That command returns nothing, btw.

By Matthew Ouille user 27 Apr 2016 at 1:02 p.m. CDT

Copy

The opt and root search returned nothing. I do believe those are just old logs. Is there a way to install Gluu other than through packages? Is there a consolidated GIT repo?

By Matthew Ouille user 27 Apr 2016 at 1:18 p.m. CDT

Copy

Actually, I think I see what's going on here. I have a virtual machine running at Linode (A host much like AWS) and so this is a container within that VM. Given that I guess all the ports really need to be proxied to the container, correct? I was expecting that this had already been done since I was seeing proxying setup through Apache, but clearly I need to proxy from my host machine TO my guest OS (Gluu) for that to happen?

By Aliaksandr Samuseu staff 27 Apr 2016 at 1:51 p.m. CDT

Copy

I don't have that much experience with Linode's vms, so it's hard for me to answer this. But Gluu's container (if we are talking about usual Gluu CE package, not a Docker edition) is a simply chroot-ed environment. So you shouldn't need any additional configurations to be able to connect to ports of applications running there via network. Connecting to the web UI is a different matter, though. It depends on which host your browser is running. If it's on the same host where your Gluu instance is located, then no additional configurations needed either. If it's on you working machine at home, then you may need to configure firewall at Gluu's vm, and, perhaps, some forwarding rules for that vm (depending on cloud service provider) **Update**: > If it's on the same host where your Gluu instance is located, then no additional configurations needed either Aside of the need to add its hostname to the /etc/hosts outside of the container too, perhaps

By Matthew Ouille user 27 Apr 2016 at 2:11 p.m. CDT

Copy

Well, I gave the container the same hostname and IP address as my host machine. Was this where my mistake was? My thought was that it should respond given what you just said.

By Matthew Ouille user 27 Apr 2016 at 2:42 p.m. CDT

Copy

I tried different hostnames with the same IP, no luck. I did just notice this though: ``` matt 3909 0.0 0.0 18480 2564 ? Sl 19:38 0:00 /opt/wrapper/bin/wrapper /opt/tomcat/conf/gluuTomcatWrapper.conf wrapper.syslog.ident=tomcat wrapper.pidfile=/var/run/tomcat/tomcat.pid wrapper.name=tomcat wrapper.displayname=Tomcat Servlet Container wrapper.daemonize=TRUE wrapper.statusfile=/var/run/tomcat/tomcat.status wrapper.java.statusfile=/var/run/tomcat/tomcat.java.status matt 3911 100 41.9 6681264 1697740 ? Sl 19:38 0:58 /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java -Djava.util.logging.config.file=/opt/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/opt/tomcat/endorsed -Dcatalina.base=/opt/tomcat -Dcatalina.home=/opt/tomcat -Djava.io.tmpdir=/opt/tomcat/temp -Djava.awt.headless=true -XX:PermSize=256m -XX:MaxPermSize=512m -Dgluu.external.resource.base=/var/gluu/webapps -Xms512m -Xmx3583m -Djava.library.path=/opt/tomcat/lib:/opt/wrapper/lib -classpath /opt/wrapper/lib/wrapper.jar:/opt/tomcat/bin/bootstrap.jar:/opt/tomcat/bin/tomcat-juli.jar -Dwrapper.key=5TCBWtORCX9KfQ63 -Dwrapper.port=32000 -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999 -Dwrapper.disable_console_input=TRUE -Dwrapper.pid=3909 -Dwrapper.version=3.5.25 -Dwrapper.native_library=wrapper -Dwrapper.arch=x86 -Dwrapper.service=TRUE -Dwrapper.cpu.timeout=10 -Dwrapper.jvmid=1 org.tanukisoftware.wrapper.WrapperStartStopApp org.apache.catalina.startup.Bootstrap 1 start org.apache.catalina.startup.Bootstrap TRUE 1 stop root 4018 0.0 0.0 64960 3980 pts/0 S 19:39 0:00 sudo service gluu-server-2.4.3 login root 4019 0.0 0.0 21252 3772 pts/0 S 19:39 0:00 /bin/bash /etc/init.d/gluu-server-2.4.3 login ``` So, the java process and the tomcat process are both running under my local user, which would lack access to serve these files as they're owned by root. I looked through the init script and didn't see much in the way of how they're not getting elevated. Any ideas?

By Matthew Ouille user 27 Apr 2016 at 2:45 p.m. CDT

Copy

A possible fix would be to create a `gluu-server` user and chown /opt/gluu-server-2.4.3 and modify the init script to load with that user, correct?

By Aliaksandr Samuseu staff 27 Apr 2016 at 2:59 p.m. CDT

Copy

> So, the java process and the tomcat process are both running under my local user That's probably because you run `ps` command outside of the container. Within the container the same user id probably belongs to "tomcat" user, which has all needed permissions (within the container). At least this is how it is in my test 2.4.3 instance

By Matthew Ouille user 27 Apr 2016 at 3:02 p.m. CDT

Copy

Very good. I found the same results. I'm still at a loss for what's going on here.

By Matthew Ouille user 27 Apr 2016 at 3:07 p.m. CDT

Copy

This was in the tomcat localhost log ``` Apr 27, 2016 7:59:21 PM org.apache.catalina.core.StandardContext listenerStop SEVERE: Exception sending context destroyed event to listener instance of class com.sun.faces.config.ConfigureListener java.lang.NullPointerException at javax.faces.component.UIViewRoot.getViewMap(UIViewRoot.java:1542) at com.sun.faces.config.InitFacesContext.release(InitFacesContext.java:237) at com.sun.faces.config.ConfigureListener.contextDestroyed(ConfigureListener.java:352) at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:5048) at org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5712) at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232) at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1590) at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1579) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) ```

By Matthew Ouille user 27 Apr 2016 at 3:09 p.m. CDT

Copy

and in the tomcat oxtrust.log ``` 2016-04-27 20:01:46,819 ERROR [org.gluu.oxtrust.ldap.service.StatusCheckerTimer] There was an error executing command check_ssl 2016-04-27 20:01:46,820 ERROR [org.gluu.oxtrust.ldap.service.StatusCheckerTimer] check_ssl retuned an unexpected value 2016-04-27 20:02:47,541 ERROR [org.gluu.oxtrust.ldap.service.StatusCheckerTimer] There was an error executing command check_ssl 2016-04-27 20:02:47,541 ERROR [org.gluu.oxtrust.ldap.service.StatusCheckerTimer] check_ssl retuned an unexpected value 2016-04-27 20:03:48,686 ERROR [org.gluu.oxtrust.ldap.service.StatusCheckerTimer] There was an error executing command check_ssl 2016-04-27 20:03:48,686 ERROR [org.gluu.oxtrust.ldap.service.StatusCheckerTimer] check_ssl retuned an unexpected value 2016-04-27 20:04:49,567 ERROR [org.gluu.oxtrust.ldap.service.StatusCheckerTimer] There was an error executing command check_ssl 2016-04-27 20:04:49,567 ERROR [org.gluu.oxtrust.ldap.service.StatusCheckerTimer] check_ssl retuned an unexpected value 2016-04-27 20:05:50,485 ERROR [org.gluu.oxtrust.ldap.service.StatusCheckerTimer] There was an error executing command check_ssl 2016-04-27 20:05:50,485 ERROR [org.gluu.oxtrust.ldap.service.StatusCheckerTimer] check_ssl retuned an unexpected value 2016-04-27 20:06:51,638 ERROR [org.gluu.oxtrust.ldap.service.StatusCheckerTimer] There was an error executing command check_ssl 2016-04-27 20:06:51,638 ERROR [org.gluu.oxtrust.ldap.service.StatusCheckerTimer] check_ssl retuned an unexpected value 2016-04-27 20:07:52,512 ERROR [org.gluu.oxtrust.ldap.service.StatusCheckerTimer] There was an error executing command check_ssl 2016-04-27 20:07:52,512 ERROR [org.gluu.oxtrust.ldap.service.StatusCheckerTimer] check_ssl retuned an unexpected value ``` Now, I am a newb with tomcat, but this seems to be a problem with the SSL module or certificate that setup.py is generating?

By Aliaksandr Samuseu staff 27 Apr 2016 at 3:46 p.m. CDT

Copy

Could you stop tomcat (`# service tomcat stop`), remove/rename `wrapper.log`, start tomcat again (the log will be re-created), wait until it has fully started (Message like "INFO: Server startup in 161068 ms" should appear there) and provide us this new wrapper.log as a whole in some way that suites you best (any file sharing service, better with privacy option)?

By Matthew Ouille user 27 Apr 2016 at 3:58 p.m. CDT

Copy

Tomcat Wrapper.log [http://pastebin.com/zUS36cy6](http://pastebin.com/zUS36cy6)

By Aliaksandr Samuseu staff 27 Apr 2016 at 4:29 p.m. CDT

Copy

Thanks, Matthew. We need some time to analyse it now. We have a [possibly] similar issue, but it's yet unclear under what conditions it may happen. We'll update you on results soon.

By Matthew Ouille user 27 Apr 2016 at 4:30 p.m. CDT

Copy

Cool man, I really appreciate you and your teams dedication.

By Aliaksandr Samuseu staff 28 Apr 2016 at 10:19 a.m. CDT

Copy

Hi, Matthew. I've been re-reading posts in this thread lately and spotted this one: > I'm in the process of regenerating the http cert and keys. Could you elaborate on this one? Depending on what you did, changing instance's Apache certificate may easily lock you out of web UI. You need to follow our guide on docs portal to do it correctly. Did you also change Apache's certificate for this very instance you provided that wrapper.log for above?

By Matthew Ouille user 28 Apr 2016 at 11:24 a.m. CDT

Copy

I've actually reinstalled the package and refreshed my VM since then. Everything I've been telling you I've done with a completely stock and vanilla install that's followed your wiki instructions to a T. So no, that apache instance you have there has the certs that are generated by setup.py

By Aliaksandr Samuseu staff 28 Apr 2016 at 1:39 p.m. CDT

Copy

Got it, thanks. Btw, are you by any chance using non-"en_US" locale for this vm? And if it's the case, may I ask you to try another install, but now in an OS installed witn "en_US" locale? Preferably the same OS you tried before.

By Matthew Ouille user 28 Apr 2016 at 1:41 p.m. CDT

Copy

Nope! Ubuntu 14.04 with en_US ``` matt@gluu:~$ locale LANG=en_US.UTF-8 LANGUAGE= LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL= ```

By Matthew Ouille user 04 May 2016 at 9:43 a.m. CDT

Copy

Hey gents, is there a known good distro this works on? I have my choice of distros. I feel like Ubuntu should've worked pretty well out of the box though. Is this possibly an issue with the kernel since I'm using 14.04.4 and the tutorial shows 14.04.2?

By Mohib Zico staff 04 May 2016 at 9:55 a.m. CDT

Copy

Matthew, I have a suggestion.... you can just grab VMWare Workstation or VirtualBox and spin a Ubuntu VM 64bit in your own computer. Assign 4GB memory and install Gluu Server. See if you can load this in your own test VM. I guess... that will help to resolve your problem what you are getting with Linode instance.

By Aliaksandr Samuseu staff 04 May 2016 at 12:22 p.m. CDT

Copy

Hi, Matthew. I'm using 14.04.4 LTS myself and have no such issues. Btw, our staff member whose logs also contained check_ssl's error message was able to resolve his issue. Remember I said before we possibly have a report on similar issue? That's what I meant, but unfortunately as it became known [his issue](https://github.com/GluuFederation/oxTrust/issues/238) had nothing to do with your case - despite he had similar error entry in logs, he still could access web UI of his instance. You still may try to apply his fix: run `# locale-gen en_US.utf8`, then `# dpkg-reconfigure locales` from within the container. Who knows, mb it will do something. We still haven't got any reports on similar problems from other users. Mb you should try to follow Zico's advice and first try to set it up on a local vm, and see what will happen.

By Matthew Ouille user 04 May 2016 at 5:04 p.m. CDT

Copy

Okay, so I've tested here on my MBP. I got the same results. Here's my abstraction: MBP > VM > Gluu I cannot access gluu from my MBP by name or IP address. The VM has the hostname of gluu.dev as does the Gluu installation. They are both tied to 10.0.2.15. The machine has 4096MB of memory. I think at this point I am fairly confident it's not an environment issue. Unless the service is not meant to be access from outside the VM, which I cannot imagine.

By Matthew Ouille user 04 May 2016 at 6:38 p.m. CDT

Copy

So, even if that was the case: From my VM I can't even access the web interface. ``` curl: (7) Failed to connect to gluu.sdlbk.net port 443: Connection refused matt@localhost:~$ curl http://gluu.sdlbk.net curl: (7) Failed to connect to gluu.sdlbk.net port 80: Connection refused matt@localhost:~$ curl http://s14.sdlbk.net ``` Nor from the container itself! ``` GLUU.root@s14:~# curl https://gluu.sdlbk.net curl: (7) Failed to connect to gluu.sdlbk.net port 443: Connection refused GLUU.root@s14:~# curl http://gluu.sdlbk.net curl: (7) Failed to connect to gluu.sdlbk.net port 80: Connection refused ``` The same situation occurs on the test VM I created on my Macbook Pro.

By Matthew Ouille user 04 May 2016 at 6:51 p.m. CDT

Copy

If one of you guys wants to reach me on Skype or EMail I can give you access to the server. I'm pretty determined this is not an issue with the environment, or it's one that is far out of my control. My other theory is that the 14.04.4 update broke Gluu due to Kernel updates.

By Aliaksandr Samuseu staff 04 May 2016 at 6:58 p.m. CDT

Copy

May I ask you to provide output of these 2 commands run on that local vm you are now using? 1. `# netstat -nlpt` from within the container. 2. `# iptables -L -n` from outside the container. Could you also try to check wrapper.log and whole set of tomcat's native logs (`catalina*`, `host-manager*`, `localhost*`, etc) for any error messages again?

By Aliaksandr Samuseu staff 04 May 2016 at 7:02 p.m. CDT

Copy

And about that: > The machine has 4096MB of memory You mean, the vm itself, right? But how much memory did you assign for tomcat when you were running setup.py script?

By Matthew Ouille user 04 May 2016 at 7:10 p.m. CDT

Copy

`netstat -nlpt` ``` Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:11211 0.0.0.0:* LISTEN 5870/memcached tcp 0 0 0.0.0.0:8022 0.0.0.0:* LISTEN 3427/sshd tcp 0 0 127.0.0.1:32000 0.0.0.0:* LISTEN 5970/java tcp6 0 0 :::1636 :::* LISTEN 3773/java tcp6 0 0 127.0.0.1:8005 :::* LISTEN 5970/java tcp6 0 0 127.0.0.1:8009 :::* LISTEN 5970/java tcp6 0 0 :::43690 :::* LISTEN 3773/java tcp6 0 0 :::8022 :::* LISTEN 3427/sshd tcp6 0 0 :::1689 :::* LISTEN 3773/java tcp6 0 0 127.0.0.1:8443 :::* LISTEN 5970/java tcp6 0 0 :::4444 :::* LISTEN 3773/java ``` IP Tables are empty. I gave tomcat 3584

By Matthew Ouille user 04 May 2016 at 7:16 p.m. CDT

Copy

So maybe the issue is that setup.py is assigning everything to localhost/127.0.0.1 instead of the public IP I supplied?

By Matthew Ouille user 04 May 2016 at 10:11 p.m. CDT

Copy

I worked with the guys at Linode and figured it out. Linode is a popular VM host just like DigitalOcean, maybe with even more features. Given that, their images have custom kernels, but you can replace them. Their custom kernel did not support AuFS. Now, with the standard kernel loaded everything is humming along. Thanks so much for your diligence gents. I'll get a blog post up of everything I did.

By Aliaksandr Samuseu staff 05 May 2016 at 11:59 a.m. CDT

Copy

Hi, Matthew, glad it was resolved. Ticket is closed already, just a note about that: >So maybe the issue is that setup.py is assigning everything to localhost/127.0.0.1 instead of the public IP I supplied? Everything is fine, these services bound to loopback interface are Gluu's internal services, they shouldn't be accessible from outside. Gluu only needs to receive external connections on tcp port 443.

By William Lowe user 19 May 2016 at 9:51 a.m. CDT

Copy

Hi Matt, Just wanted to let you know that we published your [linode deployment doc](https://gluu.org/docs/deployment/linode/). Thanks for your help! Will

You need to Login in order to post an answer

Ubuntu Web Interface Does not Load

By: Matthew Ouille user 27 Apr 2016 at 1:58 a.m. CDT

Answers

By Mohib Zico staff 27 Apr 2016 at 2:02 a.m. CDT

By Matthew Ouille user 27 Apr 2016 at 2:03 a.m. CDT

By Mohib Zico staff 27 Apr 2016 at 2:11 a.m. CDT

By Matthew Ouille user 27 Apr 2016 at 2:13 a.m. CDT

By Matthew Ouille user 27 Apr 2016 at 2:23 a.m. CDT

By Matthew Ouille user 27 Apr 2016 at 2:35 a.m. CDT

By Mohib Zico staff 27 Apr 2016 at 4:25 a.m. CDT

By Aliaksandr Samuseu staff 27 Apr 2016 at 6:45 a.m. CDT

By Matthew Ouille user 27 Apr 2016 at 11:19 a.m. CDT

By Aliaksandr Samuseu staff 27 Apr 2016 at 11:26 a.m. CDT

By Matthew Ouille user 27 Apr 2016 at 11:27 a.m. CDT

By Aliaksandr Samuseu staff 27 Apr 2016 at 11:32 a.m. CDT

By Matthew Ouille user 27 Apr 2016 at 11:34 a.m. CDT

By Aliaksandr Samuseu staff 27 Apr 2016 at 11:40 a.m. CDT

By Matthew Ouille user 27 Apr 2016 at 11:42 a.m. CDT

By Aliaksandr Samuseu staff 27 Apr 2016 at 11:55 a.m. CDT

By Aliaksandr Samuseu staff 27 Apr 2016 at 11:58 a.m. CDT

By Matthew Ouille user 27 Apr 2016 at 11:58 a.m. CDT

By Matthew Ouille user 27 Apr 2016 at 1:02 p.m. CDT

By Matthew Ouille user 27 Apr 2016 at 1:18 p.m. CDT

By Aliaksandr Samuseu staff 27 Apr 2016 at 1:51 p.m. CDT

By Matthew Ouille user 27 Apr 2016 at 2:11 p.m. CDT

By Matthew Ouille user 27 Apr 2016 at 2:42 p.m. CDT

By Matthew Ouille user 27 Apr 2016 at 2:45 p.m. CDT

By Aliaksandr Samuseu staff 27 Apr 2016 at 2:59 p.m. CDT

By Matthew Ouille user 27 Apr 2016 at 3:02 p.m. CDT

By Matthew Ouille user 27 Apr 2016 at 3:07 p.m. CDT

By Matthew Ouille user 27 Apr 2016 at 3:09 p.m. CDT

By Aliaksandr Samuseu staff 27 Apr 2016 at 3:46 p.m. CDT

By Matthew Ouille user 27 Apr 2016 at 3:58 p.m. CDT

By Aliaksandr Samuseu staff 27 Apr 2016 at 4:29 p.m. CDT

By Matthew Ouille user 27 Apr 2016 at 4:30 p.m. CDT

By Aliaksandr Samuseu staff 28 Apr 2016 at 10:19 a.m. CDT

By Matthew Ouille user 28 Apr 2016 at 11:24 a.m. CDT

By Aliaksandr Samuseu staff 28 Apr 2016 at 1:39 p.m. CDT

By Matthew Ouille user 28 Apr 2016 at 1:41 p.m. CDT

By Matthew Ouille user 04 May 2016 at 9:43 a.m. CDT

By Mohib Zico staff 04 May 2016 at 9:55 a.m. CDT

By Aliaksandr Samuseu staff 04 May 2016 at 12:22 p.m. CDT

By Matthew Ouille user 04 May 2016 at 5:04 p.m. CDT

By Matthew Ouille user 04 May 2016 at 6:38 p.m. CDT

By Matthew Ouille user 04 May 2016 at 6:51 p.m. CDT

By Aliaksandr Samuseu staff 04 May 2016 at 6:58 p.m. CDT

By Aliaksandr Samuseu staff 04 May 2016 at 7:02 p.m. CDT

By Matthew Ouille user 04 May 2016 at 7:10 p.m. CDT

By Matthew Ouille user 04 May 2016 at 7:16 p.m. CDT

By Matthew Ouille user 04 May 2016 at 10:11 p.m. CDT

By Aliaksandr Samuseu staff 05 May 2016 at 11:59 a.m. CDT

By William Lowe user 19 May 2016 at 9:51 a.m. CDT

Post an answer