Hi Kieran, I'm used to run multiple WOTaskD (having several NEXT_ROOT) on servers having multiple IP: eth0+eth1+eth2 -> bond0 & bond0:0 bond0:1 bond0:3 ... without problems, I'm following this rules: _ declare hosts/server with their IP, not their name (dns one) in JavaMonitor the HOST tab _ use 127.0.0.1 if you have only one server _ setup /etc/hosts correctly ( hostname -f have to return server.domain.tld , all ip must have a entry in /etc/hosts like: 1.2.3.4 name.domain.tld name ) _ with aliases on an iface new connections are coming from the first alias eth0:0 (or in my case bond0:0) , so the first alias got the same IP than the iface in order to have consistent source IP for outgoing connections (especially for databases connexion in my case). As a result I start using aliases for extra IP with eth0:1 (or bond0:1 ) _ disable IPv6 to avoid any problem with it.
for the current problem in addition to what Miguel says: application accept management requests only from the server where they are running (not only the ones sent by the WOTaskD). The request "STOP" which is sent by the WOTaskD of the corresponding host when you click Stop in the monitor is received by the application from an address (dns) which doesn't look like belonging to the host, so the request is refused. I have done some jad to look at what the code do for checking the source of the request and rules I have listed should be "compliant" to it. Aurelien ps: WOHost is only needed if you want to bind the TCP socket to a specific IP, WO applications listen to all IP ny default (check with lsof -n -P -i | grep LIST you 'll see *:"WOPort"), I never have to use it. Miguel Arroz a écrit : > Hi! > > The property accepts a single IP or a list of IPs (I don't know if more > than one may be useful, but why not). What you should put there is the IP > where the wotaskd requests come from. This may seem a little akward at first, > but suppose you have a subnet like 10.1.2.0/24 and your wotaskd is running > with -WOHost 10.1.2.33. This means the apps will receive the management > requests from that IP, not 127.0.0.1 or anything else that Java can identify > as localhost. > > What our class does is replace the original WO code, adding the IPs you > pass in as acceptable IPs to receive management requests from. You don't need > to call anything explicitly, as WO will do it for you (the class already > exists in WO, we are just changing it a bit, and due to WO's architecture, we > had to JAD it instead of subclassing). > > Don't worry (too much) about security issues, as WO Apps only accept > management requests that did NOT go trough the adaptor. This means that, even > if someone can fake the source IP and send you a management request trough > Apache, the WO app will detect it (the adapter adds an header) and ignore it. > Of course, do not leave the ports where the WO apps run open for the outside, > block that at your firewall. > > Yours > > Miguel Arroz > > On 2010/02/01, at 23:50, Kieran Kelleher wrote: > > >> Hmmm, thanks for replying Miguel ...... I have a few questions though ..... >> not sure if I understand fully how to use this. What, for example, might the >> value for property com.survs.localhostIps look like? >> >> For example, if my linux VM has the static IP 192.168.3.161, are you saying >> that apps running on that specific machine need the property: >> com.survs.localhostIps=192.168.3.161 >> >> or are you saying I should list *all* the hosts that run that app since the >> wotaskd on a specfic host only cares that the sender of the request is one >> of the items in the list >> >> ... and are you saying my wotaskd and app Properties files need to have >> WOHost=127.0.0.1 ?? >> >> .... and in my app, do I need to call WOHostUtilities.initLocalHosts() after >> app launch? >> >> >> >> BTW, each host has a WOHost=<ipaddress> in thr wotaskd Properties file, for >> example, the centos linux wotaskd Properties file has >> WOHost=192.168.3.161 >> >> .... just a practice I have followed since Chuck suggested it one time IIRC. >> >> -Kieran >> >> >> On Feb 1, 2010, at 4:35 PM, Miguel Arroz wrote: >> >> >>> Hey Kieran, >>> >>> Try to launch wotaskd and the apps with the flags -WOHost 127.0.0.1. We >>> have discovered recently that, in a multi-homed machine, Java will not >>> recognize some of the machine IPs as being "localhost". This causes the >>> apps to refuse management requests, which means they cannot be terminated, >>> put in "refuse new sessions" mode, etc. >>> >>> We didn't want to run the apps in the 127.0.0.1 IP for network >>> configuration reasons, so we, errr, wrote the following class. Make sure it >>> loads before the WO frameworks. Check the javadoc for details, and change >>> the property name please! ;) >>> >>> I was going to submit this to Wonder but still didn't have time, anyway, >>> Mike, Anjo, anyone, if you want to grab this and add it to Wonder, please >>> do go ahead. >>> >>> <WOHostUtilities.java> >>> >>> Yours >>> >>> Miguel Arroz >>> >>> On 2010/02/01, at 18:44, Kieran Kelleher wrote: >>> >>> >>>> Before I go off deploying my own Wonder version of wotaskd with a bunch of >>>> debugging stuff, perhaps someone has some obvious things to check for the >>>> following problem: >>>> >>>> I have apple wotaskd 5.4.3 and womonitor 5.4.3 on a Mac OS X machine. The >>>> other machines in this server group are Mac OS X and there is just one >>>> Linux Centos VM (The VM runs on OS X machine). >>>> >>>> For the Linux Centos host, all WOMonitor functionality works fine with the >>>> exception of shutdown the instance. Nothing happens when "Stop" is >>>> clicked. So, to stop or restart, I have to go and kill it on the command >>>> line. Any ideas for a "quick fix" for this (assuming this works fine for >>>> everyone else using Centos Linux WebObjects nodes) >>>> >>>> Regards, Kieran _______________________________________________ >>>> 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/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/aurelien.minet%40univ-provence.fr > > 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]
