Just to follow up, I finalized this solution by putting the property in the
"Machine properties file" for the specific server ......
that is, the file at
/etc/WebObjects/Properties
and the contents simply as:
er.extensions.WOHostUtilities.localhostips=(192.168.3.168,192.168.1.168)
This way, apps don't need special configuration and any instance of any app
that runs on that specific server gets the Miguel Arroz fiddling and the 2
local IPs for the server added as legitimate management request IPs.
Clean and simple.
Regards, Kieran
On Nov 19, 2010, at 4: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.
>
> 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". 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.
>
> 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)
>
> 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.
>
> Either way, I think it is worthwhile to drop Miguel's class into ERExtensions
> since ERExtensions, IIRC, pushes itself to the top of the classpath, and
> since Miguel's class functions the same as the original WO one if the
> localIps property is not set. Of course I will change the property name to
> have a er.extensions.* prefix.
>
> Regards, Kieran
>
>
>
>
> On Nov 19, 2010, at 4:29 PM, Chuck Hill wrote:
>
>>
>> On Nov 19, 2010, at 1:14 PM, Kieran Kelleher wrote:
>>
>>> I am not using DNS for these few machines, just their IP addresses.
>>
>> WO can be quite particular about DNS, despite what you want to do. ;-)
>>
>>
>>>
>>> hostname -f returns "localhost.localdomain"
>>>
>>> Initially the default wotaskd resulted in WOMonitor not even being able to
>>> start instances on the linux server, so adding WOHost=192.168.3.168 solved
>>> the START instance problem.
>>>
>>>
>>> On Nov 19, 2010, at 2:55 PM, Aurélien Minet wrote:
>>>
>>>> Hi Kieran
>>>>
>>>> you have to change the server's /etc/hosts to:
>>>> 127.0.0.1localhost.localdomain localhost
>>>> ::1localhost6.localdomain6 localhost6
>>>> 192.168.1.168 server.domain.tld server
>>>> 192.168.3.168 hostname.domain.tld hostname
>>>>
>>>> The line for 192.168.1.168 may not be necessary,
>>>> you may remove IPv6 line if you have not enabled it (generally I disable
>>>> IPV6 where I doesn't need it)
>>>>
>>>> what does "hostname -f " return ?
>>>>
>>>> Do you need to bind wotaskd or applications's port to 192.168.3.168 only ?
>>>> Using WOHost makes applications binding their WOPort to a specific IP.
>>>> WOHost has never been necessary for me, even if the server has multiple IP
>>>> rely on iptables if you want to just allow connections on the IP you want.
>>>> I think using WOHost only complicate things.
>>>>
>>>> Aurélien
>>>>
>>>> On 11/19/2010 07:57 PM, Kieran Kelleher wrote:
>>>>> Hi Aurélien,
>>>>>
>>>>> OK, we are only using IP addresses in WOMonitor, no hostnames at all.
>>>>>
>>>>> The linux server has two interfaces
>>>>>
>>>>> eth0192.168.1.168
>>>>> eth1192.168.3.168
>>>>>
>>>>>
>>>>> Our WOA subnet is on 192.168.3.*
>>>>>
>>>>>
>>>>> The /etc/hosts on that linux server right now has only this
>>>>>
>>>>> 127.0.0.1localhost.localdomain localhost
>>>>> ::1localhost6.localdomain6 localhost6
>>>>>
>>>>> *The wotaskd Properties file has this added:*
>>>>> WOHost=192.168.3.168
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *The wotaskd debugging output for starting an app and communication looks
>>>>> like this:*
>>>>>
>>>>> @@@@@ monitorRequestAction received request from Monitor
>>>>> [2010-11-19 13:53:37 EST] <WorkerThread1> @@@@@ monitorRequestAction
>>>>> requestDict: {commandWotaskd = ( START,
>>>>> {applicationName = "kieran-temp"; port = 2001; id = 1; hostName =
>>>>> "192.168.3.168"; } ); }
>>>>>
>>>>> [2010-11-19 13:53:37 EST] <WorkerThread1> Starting Instance:
>>>>> /opt/next/Library/WebObjects/JavaApplications/wotaskd.woa/Contents/Resources/SpawnOfWotaskd.sh
>>>>>
>>>>> /Library/WebObjects/Applications/cheetah_1787_20101119_0807.woa/cheetah_1787
>>>>> -WOHost 192.168.3.168 -WOPort 2001 -WOCachingEnabled YES
>>>>> -WODebuggingEnabled NO -WOOutputPath /dev/null -WOAutoOpenInBrowser NO
>>>>> -WOAutoOpenClientApplication NO -WOLifebeatInterval 30 -WOLifebeatEnabled
>>>>> YES -WOLifebeatDestinationPort 1085 -WOAdaptor WODefaultAdaptor
>>>>> -WOWorkerThreadCount 8 -WOListenQueueSize 128 -WOWorkerThreadCountMin 16
>>>>> -WOWorkerThreadCountMax 256 -NSProjectSearchPath () -WOSessionTimeOut
>>>>> 3600 -WOApplicationName kieran-temp -WOMonitorEnabled YES -WONoPause YES
>>>>> -Duser.name=cheetahdeploy -Dcheetah.dbhost=192.168.3.168
>>>>> -DWODirectConnectEnabled=false -DWOStatisticsPassword=temppassword
>>>>> -DEOAdaptorDebugEnabled=false -DWOAllowsConcurrentRequestHandling=true
>>>>> -DWOSessionTimeOut=900
>>>>> -Dwk.cheetah.concurrent.VendorListBillingLongResponseTask.enableTask=false
>>>>> -Xms756m -Xmx1536m
>>>>> [2010-11-19 13:53:37 EST] <WorkerThread1> @@@@@ monitorRequestAction
>>>>> returning response to Monitor
>>>>> [2010-11-19 13:53:37 EST] <WorkerThread1> @@@@@ monitorRequestAction
>>>>> responseDict: {commandWotaskdResponse = ( {success = true; } ); }
>>>>>
>>>>> [2010-11-19 13:53:37 EST] <WorkerThread4>
>>>>> @@@@@ monitorRequestAction received request from Monitor
>>>>> [2010-11-19 13:53:37 EST] <WorkerThread4> @@@@@ monitorRequestAction
>>>>> requestDict: {queryWotaskd = "INSTANCE"; }
>>>>>
>>>>> [2010-11-19 13:53:37 EST] <WorkerThread4> @@@@@ monitorRequestAction
>>>>> returning response to Monitor
>>>>> [2010-11-19 13:53:37 EST] <WorkerThread4> @@@@@ monitorRequestAction
>>>>> responseDict: {queryWotaskdResponse = {instanceResponse = ( {port = 2001;
>>>>> runningState = "STARTING"; statistics = {}; id = 1; nextShutdown = "-";
>>>>> applicationName = "kieran-temp"; refusingNewSessions = false; host =
>>>>> "192.168.3.168"; deaths = ( 11/19/2010 13:53:13 US/Eastern ); } ); }; }
>>>>>
>>>>> [2010-11-19 13:53:39 EST] <WorkerThread6> @@@@@ Received Lifebeat:
>>>>> hasStarted kieran-temp 192.168.3.168 2001
>>>>> [2010-11-19 13:53:43 EST] <main> _checkAutoRecover START
>>>>> [2010-11-19 13:53:43 EST] <main> _checkAutoRecover STOP
>>>>>
>>>>>
>>>>> *Hitting Stop on WOMonitor results in the following wotaskd output on the
>>>>> linux machine:*
>>>>>
>>>>> [2010-11-19 13:55:8 EST] <WorkerThread1>
>>>>> @@@@@ monitorRequestAction received request from Monitor
>>>>> [2010-11-19 13:55:8 EST] <WorkerThread1> @@@@@ monitorRequestAction
>>>>> requestDict: {commandWotaskd = ( STOP,
>>>>> {applicationName = "kieran-temp"; port = 2001; id = 1; hostName =
>>>>> "192.168.3.168"; } ); }
>>>>>
>>>>> [2010-11-19 13:55:8 EST] <WorkerThread1> !...@#$!@#$ sendInstanceRequest
>>>>> creates a WOHTTPConnection
>>>>> [2010-11-19 13:55:8 EST] <WorkerThread1> @@@@@ monitorRequestAction
>>>>> returning response to Monitor
>>>>> [2010-11-19 13:55:8 EST] <WorkerThread1> @@@@@ monitorRequestAction
>>>>> responseDict: {commandWotaskdResponse = ( {success = true; },
>>>>> {success = true; } ); }
>>>>>
>>>>> [2010-11-19 13:55:8 EST] <WorkerThread0>
>>>>> @@@@@ monitorRequestAction received request from Monitor
>>>>> [2010-11-19 13:55:8 EST] <WorkerThread0> @@@@@ monitorRequestAction
>>>>> requestDict: {queryWotaskd = "INSTANCE"; }
>>>>>
>>>>> [2010-11-19 13:55:8 EST] <Thread-57> !...@#$!@#$ sendInstanceRequest
>>>>> creates a WOHTTPConnection
>>>>> [2010-11-19 13:55:8 EST] <WorkerThread0> @@@@@ monitorRequestAction
>>>>> returning response to Monitor
>>>>> [2010-11-19 13:55:8 EST] <WorkerThread0> @@@@@ monitorRequestAction
>>>>> responseDict: {queryWotaskdResponse = {instanceResponse = ( {port = 2001;
>>>>> runningState = "ALIVE"; statistics = {}; id = 1; nextShutdown = "-";
>>>>> applicationName = "kieran-temp"; refusingNewSessions = false; host =
>>>>> "192.168.3.168"; deaths = ( 11/19/2010 13:53:13 US/Eastern ); } ); }; }
>>>>>
>>>>> [2010-11-19 13:55:8 EST] <WorkerThread6> @@@@@ Received Lifebeat:
>>>>> lifebeat kieran-temp 192.168.3.168 2001
>>>>> [2010-11-19 13:55:13 EST] <main> _checkAutoRecover START
>>>>> [2010-11-19 13:55:13 EST] <main> _checkAutoRecover STOP
>>>>>
>>>>>
>>>>> Any ideas about config changes to make this work?
>>>>>
>>>>>
>>>>>
>>>>> On Nov 19, 2010, at 11:49 AM, Aurélien Minet wrote:
>>>>>
>>>>>> All of the listed commands are orders passed by the wotaskd to the
>>>>>> application. The security on this is based on where
>>>>>> the orders came from. Not who, no login/password, just the IP/hostname
>>>>>> (something like gethostbyname) to check if it is
>>>>>> local or not.
>>>>>> For not having trouble, you have to make the command hostname -f
>>>>>> returning the full qualified name of the server:
>>>>>> server.domain.tld , in order to do that you have :
>>>>>> _ to get a proper /etc/hosts file like:
>>>>>> 127.0.0.1 localhost.localdomain localhost
>>>>>> 1.2.3.4 server.domainX.tld server cname.domainY.tld
>>>>>> 3.5.6.7 other.domainZ.tld other
>>>>>> ...
>>>>>> (by default it file isn't correct on OS X too but it must be
>>>>>> sufficiently correct for having wostaskd orders accepted by
>>>>>> instances)
>>>>>> _ to get the hostname correctly defined in /etc/sysconfig/network (for
>>>>>> redhat's based distribution)
>>>>>>
>>>>>> Also I would recommend that you use IP address instead of the hostname
>>>>>> in the JavaMonitor Hosts tab's in order to avoid
>>>>>> DNS problems.
>>>>>>
>>>>>> Aurélien
>>>>>>
>>>>>> On 11/19/2010 05:24 PM, Kieran Kelleher wrote:
>>>>>>> Does anyone know why a WOA app running on a physical linux (centos)
>>>>>>> machine would not respond to WOMonitor "Stop" or "Refuse New Sessions"
>>>>>>> and not display the instance statistics?
>>>>>>>
>>>>>>> What doesn't work:
>>>>>>> - WOMonitor "Stop" does not stop the instance on linux and neither does
>>>>>>> it indicate stopped in WOMonitor (as if action is ignored)
>>>>>>> - WOMonitor "Refuse New Sessions" does not stop refusing sessions on
>>>>>>> the instance and does not indicate refusing sessions in WOMonitor (as
>>>>>>> if action is ignored)
>>>>>>> - WOMonitor displays none of the statistics for the linux instance in
>>>>>>> app Detail View in WOMonitor. All zeroes.
>>>>>>>
>>>>>>> What does work for Linux instances:
>>>>>>> - WOMonitor Start does
>>>>>>> - WOMonitor Auto Recover does
>>>>>>>
>>>>>>> To save time on obvious questions, here is the configuration:
>>>>>>> - This is a mixed environment of 1 Linux and 5 OS X WOA servers.
>>>>>>> - wotaskd is Apple's 5.4.3 version on all machines
>>>>>>> - WOMonitor is Apple's 5.4.3 a Mac OS X machine
>>>>>>> - The linux machine has eth0 and eth1. eth1 is on the WOA network.
>>>>>>> - The wotaskd on the Linux box Properties file has
>>>>>>> WOHost=<eth1-ip-address>
>>>>>>> - The linux host in WOMonitor is identified by its eth1-ip-address
>>>>>>>
>>>>>>>
>>>>>>> Right now the only way to kill app instance on linux is:
>>>>>>> 1) remote login, lsof -i tcp:xxxx and then kill pid
>>>>>>> 2) Click an admin action in the instance itself that calls System.exit
>>>>>>> ... after which WOMonitor "sees" that the instance is stopped
>>>>>>>
>>>>>>> Right now the only way to refuse sessions on linux instance is:
>>>>>>> 1) Fire an admin action that calls application.refuseSessions()
>>>>>>> .... after which WOMonitor "sees" that the instance is Refusing Sessions
>>>>>>>
>>>>>>>
>>>>>>> WOMonitor functions fine for insatnces on all Mac OS X woa servers.
>>>>>>>
>>>>>>> Does anyone know what might be the problem?
>>>>>>>
>>>>>>> Regards, Kieran _______________________________________________
>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>> Webobjects-deploy mailing list ([email protected]
>>>>>>> <mailto:[email protected]>)
>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>> http://lists.apple.com/mailman/options/webobjects-deploy/aurelien.minet%40univ-provence.fr
>>>>>>>
>>>>>>> This email sent to [email protected]
>>>>>>> <mailto:[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/chill%40global-village.net
>>>
>>> This email sent to [email protected]
>>
>> --
>> Chuck Hill Senior Consultant / VP Development
>>
>> Practical WebObjects - for developers who want to increase their overall
>> knowledge of WebObjects or who are trying to solve specific problems.
>> http://www.global-village.net/products/practical_webobjects
>>
>>
>>
>>
>>
>>
>>
>
_______________________________________________
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]
