Kyle R Dunn created GEODE-4726:
----------------------------------
Summary: Documentation is misleading with a multi-homed Geode
cluster
Key: GEODE-4726
URL: https://issues.apache.org/jira/browse/GEODE-4726
Project: Geode
Issue Type: Bug
Components: configuration
Reporter: Kyle R Dunn
Trying to bind Geode to an arbitrary network interface (e.g. {{eth2}}),
requires some non-obvious parameters to be set. Some of these parameters
appear to be unrelated to multi-homing entirely, yet are necessary for both a
locator and server to start correctly.
For example, the {{--server-bind-address=w.x.y.z}} parameter appears to have no
effect on the interface used by the server process; however passing
{{--bind-address=w.x.y.z}} to the server startup produces the correct startup
behavior.
Additionally, the {{--hostname-for-clients}} parameter appears to be required
for certain Geode extensions to function once added to the {{CLASSPATH}} - in
my case it was a propriety Pivotal extension (GGC).
{code:shell}
// The following script was used successfully on Mac OS to bind to the "last"
interface listed by ifconfig (vmnet8)
#!/bin/bash
rm -rf locator1 server1
export GEODE_HOME=/opt/pivotal-gemfire-9.3.0
export CLASSPATH=${GEODE_HOME}/lib/gemfire-greenplum-3.1.1.jar
gfsh <<EOF
start locator --name=locator1 --locators=172.16.139.1[10334]
--bind-address=172.16.139.1 --port=10334 --include-system-classpath
--hostname-for-clients=172.16.139.1
start server --name=server1 --start-rest-api=true --http-service-port=28080
--locators=172.16.139.1[10334] --bind-address=172.16.139.1
--cache-xml-file=../config/ggc_cache.xml --classpath=${CLASSPATH}
--include-system-classpath
EOF
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)