Hi, Dan. I'm assuming that LB is on host different (physically) from the one hosting Gluu, correct? In that case > In the setup.py, I defined the IP and hostname of the Load Balancer ...isn't correct. The part about name was set correct, but the part about ip was not. Ip has to be always the one of the host where you are installing Gluu, almost always accepting default value will be the best choice. You need to reinstall it now.

Also, this is strange: > After reboot, /etc/sysconfig/network indicates correct hostname, however the command prompt displays ssodev.uncw.edu. Not sure whether you meant that command prompt displays it inside, or outside of the Gluu's container. You should check `/etc/sysconfig/network` for both cases. The other option could be to define a separate DNS name (an alias DNS record?) that would be used for accessing your Gluu isntance, like `idp-dev.uncw.edu` (resolving to ip of LB). Then you would need to run `setup.py` providing ip of the Gluu's host and this new DNS name to it.

Hi Aliaksandr, I still don't understand. I'm still having problems. I've actually erased the previous GLUU installed and removed directory from /opt and reinstalled GLUU. I'm using gluu-server-2.4.4 and gluu-updater-2.4.4 Background info: LB IP 152.20.5.136 LB Name ssodev.uncw.edu There is a DNS entry to match the IP to the hostname Server IP with GLUU install 152.20.5.139 Server name with GLUU install itsssodev2.dcs.uncw.edu (however, there is a DNS CNAME entry for itsssodev2.uncw.edu that resolves to 152.20.5.139) During setup.py install, I used: Enter IP Address [152.20.5.139] : Enter hostname [itsssodev2.dcs.uncw.edu] : ssodev.uncw.edu After installing and rebooting server, the hostname at the command prompt is the LB name (ssodev). Which messes up my puppet; it changes the certname in puppet to ssodev.uncw.edu. [rocker@ssodev ~]$ [rocker@ssodev ~]$ hostname -f ssodev.uncw.edu [rocker@ssodev ~]$ [rocker@ssodev ~]$ sudo cat /etc/sysconfig/network NETWORKING=yes HOSTNAME=itsssodev2.dcs.uncw.edu [rocker@ssodev ~]$

Forgot to mention, the results about the HN changing from itsssodev2 to ssodev were outside the GLUU container, they are at OS level. Inside GLUU container, command line prompt is: GLUU.[root@ssodev ~]# GLUU.[root@ssodev ~]# hostname ssodev.uncw.edu GLUU.[root@ssodev ~]# cat /etc/sysconfig/network NETWORKING=yes NOZEROCONF=yes NETWORKING_IPV6=no HOSTNAME=ssodev.uncw.eduGLUU.[root@ssodev ~]# GLUU.[root@ssodev etc]# cat hosts 127.0.0.1 localhost ::1 ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters 152.20.5.139 ssodev.uncw.edu GLUU.[root@ssodev etc]#

So, at the moment your problem is that hostname outside of the container was set to `ssodev.uncw.edu` after installing Gluu there? Have you tried to edit `cat /etc/sysconfig/network` outside of container to whatever name you need, and restart the machine? This should change it, outside of the container, at least.

Outside the container, the hostname in the /etc/sysconfig/network is correct: [rocker@ssodev ~]$ sudo cat /etc/sysconfig/network NETWORKING=yes HOSTNAME=itsssodev2.dcs.uncw.edu [rocker@ssodev ~]$ However, if you look at the prompt above, became ssodev and this was done after the GLUU install and a server reboot. Also, if one issues the command hostname at the prompt, it returns what the GLUU install changed it to: [rocker@ssodev ~]$ hostname ssodev.uncw.edu [rocker@ssodev ~]$ It also changes hostname entry in the puppet.conf file.

Let me try to summarize it: your problem is that your LB has hostname set to `ssodev.uncw.edu`, and inside of the Gluu container the same hostname is set, and persisted (you can't change it); you also have some puppet instance running **inside of the container**, and you have another one running at your LB, they both "see" the same hostname at 2 different machines, and that breaks your setup, correct? Will this be a solution? 1. You set hostname of your LB to, say, `lb-ssodev.uncw.edu` 2. You set hostname of your Gluu instance like you do it atm, to `ssodev.uncw.edu`, that will also be the hostname inside of the container (outside of it you can set any other name you need to access this machine) 3. You set a DNS alias (or CNAME record) for `ssodev.uncw.edu` resolving to `lb-ssodev.uncw.edu`, or may be simply A record for `ssodev.uncw.edu` resolving to ip address of `lb-ssodev.uncw.edu`. This will allow your puppet agents running on LB and inside container "see" different hostnames, while at the same time you'll be able to direct all external requests sent to `ssodev.uncw.edu` to your LB. Please correct me if some detail is missed.

Aliaksandr, Your solution doesn't work. The whole purpose of having a server behind a Load Balance is so that you have protection in case one server goes down and/or to balance the load. The GLUU service, when on, changes the hostname of the server to whatever is used in the setup.py script. When the hostname changes, it impacts the Puppet install. Puppet resides outside the container. Please read below for further clarification. Outside the container, my hostname (HN) is itsssodev2.dcs.uncw.edu with a DNS alias to itsssodev2.uncw.edu. The IP is 152.20.5.139. The name on the LB is ssodev.uncw.edu with an IP of 152.20.5.136. Following GLUU's instructions for installing behind a LB, I set the IP to 152.20.5.139 and set the HN to sso.dev.uncw. Once the install is done and I reboot the server, the GLUU service changes the HN of the server outside of the container to sso.dev.uncw. It doesn't change the hostname entry in the /etc/sysconfig/network file, but the GLUU service somehow changes the command prompt from itsssodev2 to ssodev (inside and outside the container). Outside the container, server becomes ssodev.uncw.edu (again, the file that contains HN entry is not altered). This impacts Puppet b/c it now thinks the hostname is ssodev.uncw.edu (puppet is not inside the GLUU container). However, what I just found out is that if I turn the GLUU service off and prevent it from coming on during reboot. The hostname stays as it should (itsssodev2.uncw.edu). I start the GLUU service up and set it start on boot, it changes the name back to ssodev.uncw.edu. Your solution doesn't work b/c the whole purpose of a LB is to have two or more servers behind a LB. Because we use Puppet on our servers to maintain a certain standard, I can't have two servers with the same name. If this doesn't convey the problem in a way that you understand, can we bring someone else in? Thanks, Dan

Hi, Dan. Please understand that free community support has its limits. Unless it's directly related to Gluu package, we usually don't spend time solving integration tasks for our free users. Many of our customers are using Gluu behind LBs successfully, so it's certainly doable. I won't claim they also use Puppet to manage their nodes, though. May be your case will turn into good feature request, but there is no ETA for such things. Still, we care about issues caused by bugs in current package. What you mentioned here > but the GLUU service somehow changes the command prompt from itsssodev2 to ssodev **(inside and outside the container)** ...looks like one. The fact hostname changes outside of the container doesn't seem to me like expected result. I'll try to reproduce it and will report it as a bug if confirmed. The fact hostname is persisted inside of the container no matter what may be a requirement placed by a chosen architecture. I would need to get a comment on this from the dev team perhaps. Does this fact also prevent you from achieving your intended setup, or do you only need to be able to change hostname outside of the container? In any case, thank you for taking your time reporting it in that much details. I'll get back to you shortly with results of my research.

Thanks Aliaksandr! In the GLUU documentation, I've read that about another person having the same issue in RHEL6. The issue is resolved in RHEL7, but our preferred platform is RHEL6.8. See ticket 3045. The main impact is that it impacts our Puppet environment. Puppet allows us to keep our servers at a standard configuration. Thanks, Dan

[Report is created](https://github.com/GluuFederation/community-edition-setup/issues/198) and you can monitor its status on github now.

Thanks Aliaksandr!

Closing it for now.