5:51 p.m.
Teiid uses host name resolution to figure out the bind address where it
can open a socket to listen for the incoming JDBC and Admin connections.
The host name resolution in Teiid has changed. See
https://jira.jboss.org/jira/browse/TEIID-1047
Previously, if user did not specify any bind address, Teiid by default
used to resolve "localhost" to WAN or LAN address and tried to
explicitly avoid the loopback (127.0.0.1) address.
The new host resolution logic does not impose any preferences, it
defaults to JDK class "InetAddress" behavior. This mimics the JBoss AS
behavior.
In most cases on individual's desktops/development stations this will
resolve to 127.0.0.1. However, if the JBoss AS is started with "-b
<host-name or ip>, then Teiid will also pick up this host name or IP
and bind to that address.
So, if you are installing Teiid on a different machine than the local,
then please start it will correct bind address/host name, such that your
remote JDBC client can connect to the server. Otherwise you will see
"connection refused" exceptions upon connect.
Let us know, if you have any questions.
Thanks.
Ramesh..
4:24 p.m.
Ramesh Reddy wrote:
Teiid uses host name resolution to figure out the bind address where
it
can open a socket to listen for the incoming JDBC and Admin connections.
The host name resolution in Teiid has changed. See
https://jira.jboss.org/jira/browse/TEIID-1047
Previously, if user did not specify any bind address, Teiid by default
used to resolve "localhost" to WAN or LAN address and tried to
explicitly avoid the loopback (127.0.0.1) address.
The new host resolution logic does not impose any preferences, it
defaults to JDK class "InetAddress" behavior. This mimics the JBoss AS
behavior.
In most cases on individual's desktops/development stations this will
resolve to 127.0.0.1. However, if the JBoss AS is started with "-b
<host-name or ip>, then Teiid will also pick up this host name or IP
and bind to that address.
So, if you are installing Teiid on a different machine than the local,
then please start it will correct bind address/host name, such that your
remote JDBC client can connect to the server. Otherwise you will see
"connection refused" exceptions upon connect.
So by default, the server will not be able to accept remote JDBC
connections? I see the security benefits of this behavior but also
end-user inconvenience. Does the hostname or IP specified with -b have
to match *exactly* with the hostname string in the JDBC URL used by
client applications? Or will it work as long as it resolves down to the
same IP address (I assume the latter but just checking)?
Also, how will this impact Teiid firewall configuration and dynamic IP
environments like Amazon EC2 where internal and external addresses differ?
Thx,
-Ken
Let us know, if you have any questions.
Thanks.
Ramesh..
_______________________________________________
teiid-users mailing list
teiid-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-users
--
Ken Johnson
Sr. Product Manager
JBoss Middleware Business Unit
Red Hat, Inc
978.392.3917
ken.johnson(a)redhat.com
4:16 p.m.
On Mon, 2010-04-19 at 10:24 -0400, Ken Johnson wrote:
So by default, the server will not be able to accept remote JDBC
connections? I see the security benefits of this behavior but also
end-user inconvenience.
Yes, I agree that this is little inconvenience to the
users out of the
box. The primary driving factors were
1) Security
2) Align the host resolution to be similar to the JBoss AS, so that
users are not given two different choices in configuring the bind
address.
The logic changed *if* the host name resolves "localhost" (mostly
developer machines), however like in any typical shared server
environment would have their host name specified, so they will resolve
to proper LAN address that will be reachable by the known name.
Does the hostname or IP specified with -b have
to match *exactly* with the hostname string in the JDBC URL used by
client applications? Or will it work as long as it resolves down to
the
same IP address (I assume the latter but just checking)?
If they resolve to same IP that would be enough. If the sever is started
with "0.0.0.0" then any resolved IP on that machine will be fine. Also,
note that user could still provide the host name/ip in the Teiid
configuration to override the default behavior.
Also, how will this impact Teiid firewall configuration and dynamic
IP
environments like Amazon EC2 where internal and external addresses
differ?
I do not know. Do these offer IP forwarding services may be?
Ramesh..
9:26 p.m.
On Mon, 2010-04-19 at 10:16 -0400, Ramesh Reddy wrote:
On Mon, 2010-04-19 at 10:24 -0400, Ken Johnson wrote:
> So by default, the server will not be able to accept remote JDBC
> connections? I see the security benefits of this behavior but also
> end-user inconvenience.
Yes, I agree that this is little inconvenience to the users out of the
box. The primary driving factors were
1) Security
2) Align the host resolution to be similar to the JBoss AS, so that
users are not given two different choices in configuring the bind
address.
The logic changed *if* the host name resolves "localhost" (mostly
developer machines), however like in any typical shared server
environment would have their host name specified, so they will resolve
to proper LAN address that will be reachable by the known name.
> Does the hostname or IP specified with -b have
> to match *exactly* with the hostname string in the JDBC URL used by
> client applications? Or will it work as long as it resolves down to
> the
> same IP address (I assume the latter but just checking)?
>
If they resolve to same IP that would be enough. If the sever is started
with "0.0.0.0" then any resolved IP on that machine will be fine. Also,
note that user could still provide the host name/ip in the Teiid
configuration to override the default behavior.
> Also, how will this impact Teiid firewall configuration and dynamic
> IP
> environments like Amazon EC2 where internal and external addresses
> differ?
I do not know. Do these offer IP forwarding services may be?
This primarily deals with issues in the past regarding clustering.
Basically, in the past, a client would make a JDBC connection to the
server and ask for a resource list. The server would create a list of
resources which contains the host name and TCP port number for the
services. The server would use the "host name" property configured at
installation time. So, if I were to install the server and say its host
name was myteiidhost.com then even when a client would connect using a
host name of public.myteiidhost.com the server would return a resource
list which only included host names of myteiidhost.com. If this host
name was not resolvable by the client, the connection would fail mid-way
through. The firewall property was introduced to account for this. If
the firewall property was defined to include a value of
public.myteiidhost.com then the resource list would be rewritten to use
the host name the client used rather then the host name used at server
installation time.
Is this still an issue? Does Teiid server create a resource list that
contains host names/ports?
--
Larry O'Leary
Middleware Support Engineering Group
Global Support Services
Red Hat, Inc.
loleary(a)redhat.com
1.866.LINUX70 (+1.314.336.2990) xt 81-62909
Office: +1.314.336.2909
Mobile: +1.618.420.7623
--
Looking to carve out IT costs?
http://www.redhat.com/carveoutcosts/
10:18 p.m.
On Mon, 2010-04-19 at 14:26 -0500, Larry O'Leary wrote:
Is this still an issue? Does Teiid server create a resource list
that
contains host names/ports?
No, it does not send the server's view of the host names to the client
any more. The automatic discovery of server is currently not supported.
Teiid still needs to implement clustering, we will hash out details
then. Until that time, if there are more than one Teiid server, they all
can be specified on the connection URL for load balancing and fail over.
Ramesh..
5:58 p.m.
Regarding the firewall issue:
http://community.jboss.org/wiki/UsingJBossBehindAFirewall
snippet:
Then, on the system behind the firewall, the following parameters need to be added to the
java command line in the run.sh script to pass back the "correct" RMI
information to the system outside of the firewall.
"Correct" in this case means the hostname that the outside system refers to
when addressing the system behind the firewall.
-Djava.rmi.server.hostname=<external_host_name>
-Djava.rmi.server.useLocalHostname=true
It looks like java.rmi.server.hostname property provided what the MMx firewall address
provided.
On Apr 19, 2010, at 9:16 AM, Ramesh Reddy wrote:
On Mon, 2010-04-19 at 10:24 -0400, Ken Johnson wrote:
> So by default, the server will not be able to accept remote JDBC
> connections? I see the security benefits of this behavior but also
> end-user inconvenience.
Yes, I agree that this is little inconvenience to the users out of the
box. The primary driving factors were
1) Security
2) Align the host resolution to be similar to the JBoss AS, so that
users are not given two different choices in configuring the bind
address.
The logic changed *if* the host name resolves "localhost" (mostly
developer machines), however like in any typical shared server
environment would have their host name specified, so they will resolve
to proper LAN address that will be reachable by the known name.
> Does the hostname or IP specified with -b have
> to match *exactly* with the hostname string in the JDBC URL used by
> client applications? Or will it work as long as it resolves down to
> the
> same IP address (I assume the latter but just checking)?
>
If they resolve to same IP that would be enough. If the sever is started
with "0.0.0.0" then any resolved IP on that machine will be fine. Also,
note that user could still provide the host name/ip in the Teiid
configuration to override the default behavior.
> Also, how will this impact Teiid firewall configuration and dynamic
> IP
> environments like Amazon EC2 where internal and external addresses
> differ?
I do not know. Do these offer IP forwarding services may be?
Ramesh..
_______________________________________________
teiid-users mailing list
teiid-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-users
Van Halbert
Principal Software Eng.
Red Hat, Inc.
------
vhalbert(a)redhat.com
6:58 p.m.
On Tue, 2010-04-20 at 10:58 -0500, Van Halbert wrote:
Regarding the firewall issue:
http://community.jboss.org/wiki/UsingJBossBehindAFirewall
snippet:
Then, on the system behind the firewall, the following parameters need
to be added to the java command line in the run.sh script to pass back
the "correct" RMI information to the system outside of the firewall.
"Correct" in this case means the hostname that the outside system
refers to when addressing the system behind the firewall.
-Djava.rmi.server.hostname=<external_host_name>
-Djava.rmi.server.useLocalHostname=true
It looks like java.rmi.server.hostname property provided what the MMx
firewall address provided.
But this is applicable to an RMI client. Is our JDBC client connection
simply an RMI connection?
If the server isn't creating a registry list which refers to the
server's host name or IP address, this shouldn't be an issue as long as
port forwarding, NAT, or the proxy are configured correctly.
Now, clustering will be a different issue and if we are not using RMI
then we will need to introduce something similar to what RMI is doing or
what we previously had but on a per host/VM level.
On Apr 19, 2010, at 9:16 AM, Ramesh Reddy wrote:
> On Mon, 2010-04-19 at 10:24 -0400, Ken Johnson wrote:
> > So by default, the server will not be able to accept remote JDBC
> > connections? I see the security benefits of this behavior but
> > also
> > end-user inconvenience.
> Yes, I agree that this is little inconvenience to the users out of
> the
> box. The primary driving factors were
>
> 1) Security
> 2) Align the host resolution to be similar to the JBoss AS, so that
> users are not given two different choices in configuring the bind
> address.
>
> The logic changed *if* the host name resolves "localhost" (mostly
> developer machines), however like in any typical shared server
> environment would have their host name specified, so they will
> resolve
> to proper LAN address that will be reachable by the known name.
>
> > Does the hostname or IP specified with -b have
> > to match *exactly* with the hostname string in the JDBC URL used
> > by
> > client applications? Or will it work as long as it resolves down
> > to
> > the
> > same IP address (I assume the latter but just checking)?
> >
> If they resolve to same IP that would be enough. If the sever is
> started
> with "0.0.0.0" then any resolved IP on that machine will be fine.
> Also,
> note that user could still provide the host name/ip in the Teiid
> configuration to override the default behavior.
>
> > Also, how will this impact Teiid firewall configuration and
> > dynamic
> > IP
> > environments like Amazon EC2 where internal and external addresses
> > differ?
> I do not know. Do these offer IP forwarding services may be?
>
> Ramesh..
>
> _______________________________________________
> teiid-users mailing list
> teiid-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-users
>
Van Halbert
Principal Software Eng.
Red Hat, Inc.
------
vhalbert(a)redhat.com
_______________________________________________
teiid-users mailing list
teiid-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-users
--
Larry O'Leary <loleary(a)redhat.com>
Red Hat, Inc.
2:45 p.m.
On Tue, 2010-04-20 at 11:58 -0500, Larry O'Leary wrote:
> It looks like java.rmi.server.hostname property provided what
the
MMx
> firewall address provided.
>
But this is applicable to an RMI client. Is our JDBC client
connection
simply an RMI connection?
No, it is not an RMI connection. Teiid simulates the JDBC protocol over
plain socket connection.
If the server isn't creating a registry list which refers to the
server's host name or IP address, this shouldn't be an issue as long
as
port forwarding, NAT, or the proxy are configured correctly.
Now, clustering will be a different issue and if we are not using RMI
then we will need to introduce something similar to what RMI is doing
or
what we previously had but on a per host/VM level.
Since the basic clustering is
provided by the application server, we
need to see how this play out during the development. Right now I do not
have any details.
Ramesh..
5113
days inactive
5124
days old
7 comments
4 participants
participants (4)
-
Ken Johnson -
Larry O'Leary -
Ramesh Reddy -
Van Halbert