Hi!

 (Sorry, Aurélien, I forgot to include the list in cc...)

 I don't remember all the details now, because some time has passed since I 
wrote that class.

 Anyway, the main idea behind was simple: for some reason, the JVM won't report 
the full list of local addresses when requested to do so via the correct API. 
This means that, if you have a multi-homed machine, you won't get all the IP 
addresses assigned to the local interfaces as the result of that API.

 The fix I sent to the list a few months ago allows you to define, in the 
properties, the addresses you want to be considered local. This will add your 
addresses to the ones already considered local by the JVM (like 127.0.0.1).

 What's the point of all this? IIRC, we had servers with two network interfaces 
- one in a private network (10.* addresses or so) and one with public IPs 
facing the public Internet. Given this, we decided to make everything run on 
internal IPs, except apache. This way, all the requests between apache adaptor 
and apps, apache adaptor and wotaskd's, womonitor and everything else, etc, 
would happen in the private, secured network. This had the side effect of 
making the admin http requests that came from wotaskd to the apps (requesting 
to terminate or turn on refusal of instances, for example) having the source 
address as being 10.* instead of 127.0.0.1.

 If you peek at the original code, you'll see those requests are ignored unless 
they come from a local IP. So, I wrote that class to tell WO my 10.* address 
was also a local IP.

 I remember we tried to do some of the stuff you describe, like playing with 
the hosts file, but it was of no use. As long as we binded the WO 
infrastructure to our private network IPs, nothing would solve the issue but 
that code change.

 BTW this happened on FreeBSD. YMMV with other OS'es.

 Regards,

Miguel Arroz

On 2010/11/19, at 23:21, Aurélien Minet wrote:

> glad to see it is resolved
> 
> On 11/19/2010 10:50 PM, Kieran Kelleher wrote:
>> OK, first of all. Thanks to all who tried to help.
>> 
>> Miguel Arroz - you are a very smart man, and you should never give up your 
>> WO career for goat-herding or farming in Portugal! :-)
>> 
>> So here is what worked for the finicky multi-IP linux box and its on/off 
>> relationship with wotaskd:
>> 
>> I added Miguel's WOHostUtilities to ERExtensions, built and deployed the app.
> I don't know Miguel's WOHostUtilities what is it made for ?
>> Note, WOHost needed to be set in wotaskd's Properties to the 
>> WoHost=192.168.3.168. Setting it specifically to 127.0.0.1 resulted in 
>> WOMonitor red error message "Failed to contact 192.168.3.168-1085".
> Yes it's normal the WOPort of wotaskd isn't binded to 192.168.3.168 but 
> 127.0.0.1 so no connection from the outside could be made.  using 127.0.0.1 
> is for setup with only one server.
>>  Not setting it at all resulted in that Linux wotaskd not even receiving 
>> requests from WOMonitor (confirmed with wotaskd debugging enabled) and not 
>> responding at all to START instance requests.
> If your hostname is localhost.localdomain as it correspond to 127.0.0.1 you 
> have to declare the host in JavaMonitor as 127.0.0.1 but with this setup you 
> can only have one server.
> Only use localhost.localdomain for hostname if the server will be the only 
> WebObjects server (declared in the JavaMonitor as 127.0.0.1 or 
> localhost.localdomain)
> 
> In your case:
> * no DNS server
> * private LAN
> * multiple WebObjects servers
> 
> you need :
> * to set a hostname, ex: srvwo168.wo.local   (or anything else but not 
> localhost.localdomain)
> * add the line:  "192.168.3.168 srvwo168.local srvwo168"  in /etc/hosts on 
> srvwo168 (eventually on the server where JavaMonitor is running)
>  (even if DNS server can have hight availability, I don't rely on them only, 
> I always put in  /etc/hosts all WO servers, Apache servers and databases 
> servers)
> * no need to use WOHost, all applications including wotaskd will bind their 
> WOPort to all IP
> 
> with this kind of setup :
>  _ applications will accept orders from the wotaskd as when they lookup where 
> the orders came from they found they were coming from the local server
>  _ wotaskd will start applications  as it knows itself in the SiteConfig.xml  
> as 192.168.3.168 and finds that 192.168.3.168 is one of the server's IP .
> 
> note that it isn't specific to Linux, but applies to OS X,  Solaris, FreeBSD 
> ...
>> In WOMonitor I added a single argument with a list of all IP addresses of 
>> all wotaskd hosts in the WOA subnet, like this:
>> 
>> -Dcom.survs.localhostIps=(192.168.3.140,192.168.3.160,192.168.3.163,192.168.3.165,192.168.3.161,192.168.3.161,192.168.3.168)
> this is needed by Miguel's WOHostUtilities ?  I understand that is the IP 
> list of your WebObjects servers but it's used to provide what functionality ?
> ( IP/hostname of WebObjects servers are in the SiteConfig.xml)
>> Now WOMonitor works for linux instances the same as for Mac OS X instances. 
>> Yay! :-)
>> 
>> I am guessing (but not going messing with this server right now since it has 
>> other services running on it that cannot be stopped for me to experiment) 
>> that if the eth0 was on the WOA subnet, none of this might be neccessary.
> No, you only need to make the server configuration right at the "dns" 
> (/etc/hosts) and hostname level, regardless the number of network cards or IP 
> addresses the server got.
> In the case you don't want the hostname (ex: mysrv.local) to match a specific 
> IP, network card or subnet , you can declare it to 127.0.0.1 in /etc/hosts on 
> the server with a line like :
> 127.0.0.1 localhost.localdomain localhost mysrv.local mysrv
> 
> I hope all the mails in the thread will help future WebObjects servers setup
> 
> Regards
> 
> Aurélien
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-deploy mailing list      ([email protected])
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/webobjects-deploy/arroz%40guiamac.com
> 
> This email sent to [email protected]


 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-deploy mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-deploy/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to