Re: Storing a user in a cookie
I think that first you have to think seriously if you really want to do this. There are two problems to guard against - making up tokens, and re-using other people's. Encryption might fix the first, but not the second. If you do REALLY want to do it, you have to basically emulate a session ID, and store that in the database or in a file or something, and then look it up - with some sort of expiry period built in. You can generate the tokens with a hash function, it doesn't need to be reversible encryption. If there is no expiry mechanism then anyone who has access to your token (e.g., from sniffing network traffic) from the cookie can masquerade as that user at any time (years later even), bypassing authentication, and you have no way to stop them short of invalidating the user id. Session id's are always a bit of a trade off security wise, but you need some way to check that the return of the user is plausible and not just accept any connection that knows the magic words. Simon CISSP-ISSAP, ISSMP, GWAPT, OSWP Sent from my iPhone On Feb 20, 2013, at 11:08 AM, Jesse Tayler jtay...@oeinc.com wrote: you're only going to compare one resulted cypher to another resulted cypher you have stored -- knowing they calculate to the same result and are the same/correct is enough to ensure people haven't just made up a cookie and you'd never reveal a cookie that would be useful. On Feb 20, 2013, at 12:02 PM, Pascal Robert prob...@macti.ca wrote: What would you use for storing details about an user in a cookie for stateless apps (e.g., in a keep me logged situation)? I see two solutions: - Using BlowFish to encrypt the username in the cookie, and to decrypt the value of the cookie to see who is the user; - Encrypting the username with BCrypt, storing the encrypted username in the database and in the cookie, and doing a comparison. Opinions? The only problem I see with the first one is that if someone find the cipher key, you're toast, but at the same time, if they find it, it's probably because it was stored in the file system or in a SCM, so if they found it, you will probably have other problems too. ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/jtayler%40oeinc.com This email sent to jtay...@oeinc.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/sjoliver%40memphis.edu This email sent to sjoli...@memphis.edu ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Fwd: Storing a user in a cookie
Forgot to copy the list... Sent from my iPhone Begin forwarded message: From: Simon J Oliver (sjoliver) sjoli...@memphis.edumailto:sjoli...@memphis.edu Date: February 20, 2013, 8:23:33 PM CST To: Ken Anderson kenli...@anderhome.commailto:kenli...@anderhome.com Subject: Re: Storing a user in a cookie Yes I think OAuth could potentially work, although you'd probably want some sort of local session management /caching anyway to avoid the need to validate every request with the identity provider. OAuth has the advantage at least over Pascal's original scheme that it provides an form of expiry/invalidation mechanism that allows a token to be repudiated if needed. Depending on how long you want the tokens to live and/or how sensitive the data is, you'd probably want to ensure that your app was served solely over SSH to minimize the risk of token theft. It really all depends on you, your users and your data... I can't imagine many circumstances where just re-locking the door to fix a confidentiality/integrity breach after the fact is a 'good enough' solution to keeping an app secure (especially where the breach can have happened through no identifiable fault of the user, as in the case of tokens sniffed off the network) but if that works for your scenario, then that's great. :-) Simon Sent from my iPhone On Feb 20, 2013, at 11:36 AM, Ken Anderson kenli...@anderhome.commailto:kenli...@anderhome.com wrote: Doesn't OAUTH do exactly what you're asking for? For users that use one of my iOS apps (RailTime), we get an OAUTH secret from Twitter that's unique to us. The user can always log onto Twitter and disable our OAUTH secret, but otherwise it lasts forever. If a user complains that they're seeing strange behavior on their account, revoke the secret and issue another one. Ken On Feb 20, 2013, at 10:24 AM, Simon J Oliver (sjoliver) sjoli...@memphis.edumailto:sjoli...@memphis.edu wrote: I think that first you have to think seriously if you really want to do this. There are two problems to guard against - making up tokens, and re-using other people's. Encryption might fix the first, but not the second. If you do REALLY want to do it, you have to basically emulate a session ID, and store that in the database or in a file or something, and then look it up - with some sort of expiry period built in. You can generate the tokens with a hash function, it doesn't need to be reversible encryption. If there is no expiry mechanism then anyone who has access to your token (e.g., from sniffing network traffic) from the cookie can masquerade as that user at any time (years later even), bypassing authentication, and you have no way to stop them short of invalidating the user id. Session id's are always a bit of a trade off security wise, but you need some way to check that the return of the user is plausible and not just accept any connection that knows the magic words. Simon CISSP-ISSAP, ISSMP, GWAPT, OSWP Sent from my iPhone On Feb 20, 2013, at 11:08 AM, Jesse Tayler jtay...@oeinc.commailto:jtay...@oeinc.com wrote: you're only going to compare one resulted cypher to another resulted cypher you have stored -- knowing they calculate to the same result and are the same/correct is enough to ensure people haven't just made up a cookie and you'd never reveal a cookie that would be useful. On Feb 20, 2013, at 12:02 PM, Pascal Robert prob...@macti.camailto:prob...@macti.ca wrote: What would you use for storing details about an user in a cookie for stateless apps (e.g., in a keep me logged situation)? I see two solutions: - Using BlowFish to encrypt the username in the cookie, and to decrypt the value of the cookie to see who is the user; - Encrypting the username with BCrypt, storing the encrypted username in the database and in the cookie, and doing a comparison. Opinions? The only problem I see with the first one is that if someone find the cipher key, you're toast, but at the same time, if they find it, it's probably because it was stored in the file system or in a SCM, so if they found it, you will probably have other problems too. ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.commailto:Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/jtayler%40oeinc.com This email sent to jtay...@oeinc.commailto:jtay...@oeinc.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.commailto:Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/sjoliver%40memphis.edu This email sent to sjoli...@memphis.edumailto:sjoli...@memphis.edu
Re: Storing a user in a cookie
Long day 'application served solely over SSL' is what I meant, of course. Sent from my iPhone On Feb 20, 2013, at 8:26 PM, Simon J Oliver (sjoliver) sjoli...@memphis.edumailto:sjoli...@memphis.edu wrote: Forgot to copy the list... Sent from my iPhone Begin forwarded message: From: Simon J Oliver (sjoliver) sjoli...@memphis.edumailto:sjoli...@memphis.edu Date: February 20, 2013, 8:23:33 PM CST To: Ken Anderson kenli...@anderhome.commailto:kenli...@anderhome.com Subject: Re: Storing a user in a cookie Yes I think OAuth could potentially work, although you'd probably want some sort of local session management /caching anyway to avoid the need to validate every request with the identity provider. OAuth has the advantage at least over Pascal's original scheme that it provides an form of expiry/invalidation mechanism that allows a token to be repudiated if needed. Depending on how long you want the tokens to live and/or how sensitive the data is, you'd probably want to ensure that your app was served solely over SSH to minimize the risk of token theft. It really all depends on you, your users and your data... I can't imagine many circumstances where just re-locking the door to fix a confidentiality/integrity breach after the fact is a 'good enough' solution to keeping an app secure (especially where the breach can have happened through no identifiable fault of the user, as in the case of tokens sniffed off the network) but if that works for your scenario, then that's great. :-) Simon Sent from my iPhone On Feb 20, 2013, at 11:36 AM, Ken Anderson kenli...@anderhome.commailto:kenli...@anderhome.com wrote: Doesn't OAUTH do exactly what you're asking for? For users that use one of my iOS apps (RailTime), we get an OAUTH secret from Twitter that's unique to us. The user can always log onto Twitter and disable our OAUTH secret, but otherwise it lasts forever. If a user complains that they're seeing strange behavior on their account, revoke the secret and issue another one. Ken On Feb 20, 2013, at 10:24 AM, Simon J Oliver (sjoliver) sjoli...@memphis.edumailto:sjoli...@memphis.edu wrote: I think that first you have to think seriously if you really want to do this. There are two problems to guard against - making up tokens, and re-using other people's. Encryption might fix the first, but not the second. If you do REALLY want to do it, you have to basically emulate a session ID, and store that in the database or in a file or something, and then look it up - with some sort of expiry period built in. You can generate the tokens with a hash function, it doesn't need to be reversible encryption. If there is no expiry mechanism then anyone who has access to your token (e.g., from sniffing network traffic) from the cookie can masquerade as that user at any time (years later even), bypassing authentication, and you have no way to stop them short of invalidating the user id. Session id's are always a bit of a trade off security wise, but you need some way to check that the return of the user is plausible and not just accept any connection that knows the magic words. Simon CISSP-ISSAP, ISSMP, GWAPT, OSWP Sent from my iPhone On Feb 20, 2013, at 11:08 AM, Jesse Tayler jtay...@oeinc.commailto:jtay...@oeinc.com wrote: you're only going to compare one resulted cypher to another resulted cypher you have stored -- knowing they calculate to the same result and are the same/correct is enough to ensure people haven't just made up a cookie and you'd never reveal a cookie that would be useful. On Feb 20, 2013, at 12:02 PM, Pascal Robert prob...@macti.camailto:prob...@macti.ca wrote: What would you use for storing details about an user in a cookie for stateless apps (e.g., in a keep me logged situation)? I see two solutions: - Using BlowFish to encrypt the username in the cookie, and to decrypt the value of the cookie to see who is the user; - Encrypting the username with BCrypt, storing the encrypted username in the database and in the cookie, and doing a comparison. Opinions? The only problem I see with the first one is that if someone find the cipher key, you're toast, but at the same time, if they find it, it's probably because it was stored in the file system or in a SCM, so if they found it, you will probably have other problems too. ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.commailto:Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/jtayler%40oeinc.com This email sent to jtay...@oeinc.commailto:jtay...@oeinc.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.commailto:Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update
Re: JavaMonitor wotask SSD Problem.
I'm not sure you'd need to restart Apache if you could wait and start the WO processes at the right time. Or maybe you would, simply because if it starts too soon, as well. I'm working on setting up a new deployment environment, and was going to work on fleshing out that skeleton code. I'll share it here when I have it finished. On Feb 29, 2012, at 7:43 PM, Gaastra Dennis - WO Lists wrote: Now what booting script do you use to delay starting up wotaskd + JavaMonitor, and do an apache restart afterwards? Something similar to what Simon suggested? Thanks Dennis On 28/Feb/12 11:49 PM, Chuck Hill wrote: Yes. Four. :-) On Feb 29, 2012, at 12:48 PM, Gaastra Dennis - WO Lists webobjects_li...@webappz.commailto:webobjects_li...@webappz.com wrote: and the webobjects apache configuration WebObjectsConfig http://http:/hostname:1085 10 On 28/Feb/12 7:49 PM, Chuck Hill wrote: All three of wotaskd, java monitor, and your apps need to agree on WOHost On Feb 29, 2012, at 8:52 AM, Gaastra Dennis - WO Lists webobjects_li...@webappz.commailto:webobjects_li...@webappz.com wrote: Hi Ken et al, After restarting the launchdaemons, Monitor seems to be happy with its instances showing as running, but we still get the famous The requested application was not found on this server. Thanks Dennis. On 27/Feb/12 10:41 PM, ISHIMOTO Ken wrote: Hi, It looks we have a problem with JavaMonitor and wotask, that had to be fixed. I have seen this Problem now on several Machines, and found the problem, but think about a fix. Maybe the only way is to fix the Apps Javacode itself... Test Machine was OS X Lion OS X SnowLeopard What is going on: The correctway : If the Machine starts * LaunchD starts the Database * LaunchD start JavaMonitor wotask * wotask will start the Instances * Everybody is Happy The Problem only appears if the Boot disk is a SSD Drive. * LaunchD starts the Database * LaunchD start JavaMonitor wotask BUT, JavaMonitor and wotask Launches and try to get the Network Interface for making work, the OS Networking isn't setup at that time. The Boot was to fast. Both Apps try for several time, and give up. But running. a Zombi process * wotask can't start the Instances The only way after the Launch is to go to Activity Monitor to kill both processes, LaunchD will boot both again and everybody is happy. 1. Fix 1 : LaunchD Script - I have no idea if that is possible to say launch at Boot but delayed or so 2. Fix 2 : In the javacode after retry the App and can't get a Connection kill itself, and let launchD boot it again.. Thank you Ken Ishimoto K's ROOM [E-Mail] k...@ksroom.commailto:k...@ksroom.com [iChat:] ibase_...@mac.commailto:ibase_...@mac.com [HP] http://www.ksroom.com/ _ This e-mail has not been scanned for viruses because it was written on an Mac, and there are NO Viruses on an Apple Computer. For further information visit http://www.apple.comhttp://www.apple.com/ ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.commailto:Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/webobjects_lists%40webappz.com This email sent to webobjects_li...@webappz.commailto:webobjects_li...@webappz.com -- With Kind Regards, Dennis Gaastra, WEBAPPZ® Systems, Inc. (+1) 604.921.1333 www.webappz.comhttp://www.webappz.com/ www.scheduleDS.comhttp://www.scheduleDS.com/ www.1tracker.comhttp://www.1tracker.com/ This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. WEBAPPZ Systems, Inc., 726 - 1489 Marine Drive, West Vancouver, BC, CANADA V7T 1B8, www.webappz.comhttp://www.webappz.com/ ___ Do not post admin requests to
Re: JavaMonitor wotask SSD Problem.
I was just diffing the application launch scripts for a default
wotaskd/javamonitor that I had lying around (not exactly sure which version -
probably from 5.3.x) and the Wonder versions - i.e., wotaskd.woa/wotaskd and
JavaMonitor.woa/JavaMonitor (not the launchd code).
In both cases the stock versions include the following code right before the
application is launched - and which is not present in the Wonder versions of
the apps (or in my own built apps):
# Verify network services are intialized before starting
#
echo Checking network services
if [ ${PLATFORM_TYPE} = Darwin ]
then
/usr/sbin/ipconfig waitall
fi
#
It seems that Apple recognized this problem, and took steps to customize each
of these 'likely to be launched boot time' applications' boot scripts to deal
with it.
Is there a way to build the Wonder versions to include modified launch scripts
by default? Alternatively, I think you could go with my earlier idea of a
dedicated launchd task to wait for the interfaces at that point, and then bring
up wotaskd, Monitor and Apache once the network is ready.
Simon
On Mar 1, 2012, at 1:21 PM, gsbr...@umich.edumailto:gsbr...@umich.edu
gsbr...@umich.edumailto:gsbr...@umich.edu wrote:
I recall modifying the app.woa/app startup script at the end.
Basically, wotaskd should start first (it will start your app), then after it
is running javamonitor should start. The tail end of my wotaskd.woa/wotaskd is
like:
#
# Launch the application.
#
# gsb 6/9/2010
# wait untill things boot all the way up
/usr/sbin/ipconfig waitall
#extra time for db
/bin/sleep 100
#
# Launch the application.
#
echo gb fixed? Launching ${SCRIPT_NAME}.woa ...
echo Launching ${SCRIPT_NAME}.woa ...
echo ${JAVA_EXECUTABLE} ${JAVA_EXECUTABLE_ARGS} -classpath WOBootstrap.jar
com.webobjects._bootstrap.WOBootstrap ${COMMAND_LINE_ARGS}
eval exec ${JAVA_EXECUTABLE} ${JAVA_EXECUTABLE_ARGS} -classpath WOBootstrap.jar
com.webobjects._bootstrap.WOBootstrap ${COMMAND_LINE_ARGS}
And for my JavaMonitor.woa/JavaMonitor:
# gsb 6/9/2010
# wait untill things boot all the way up
/usr/sbin/ipconfig waitall
#extra time for db
/bin/sleep 240
#
# Launch the application.
#
echo gb fixed? Launching ${SCRIPT_NAME}.woa ...
#
# Launch the application.
#
echo Launching ${SCRIPT_NAME}.woa ...
echo ${JAVA_EXECUTABLE} ${JAVA_EXECUTABLE_ARGS} -classpath WOBootstrap.jar
com.webobjects._bootstrap.WOBootstrap ${COMMAND_LINE_ARGS}
eval exec ${JAVA_EXECUTABLE} ${JAVA_EXECUTABLE_ARGS} -classpath WOBootstrap.jar
com.webobjects._bootstrap.WOBootstrap ${COMMAND_LINE_ARGS}
So I had javamonitor trying to restart wotaskd which was waiting for things to
happen. This did not allow proper startup. With the wait and extra time for
javamonitor reboots work properly.
I think the apple wo 5.4.3 startups had some waiting; this is the Wonder
versions I had to modify.
A wait maybe should be added to the Wonder wotaskd and JavaMonitor startup
scripts.
I could be wrong, of course.
Greg Brown
gsbr...@umich.edumailto:gsbr...@umich.edu
--
gsbr...@umich.edumailto:gsbr...@umich.edu
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list
(Webobjects-dev@lists.apple.commailto:Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/sjoliver%40memphis.edu
This email sent to sjoli...@memphis.edu
--
Simon J. Oliver
MA (Cantab.)
CISSP-ISSAP, ISSMP, GWAPT, OSWP
Information, Architecture Data Security Consultant
Applied Information Technology Center/SBBER
University of Memphis, TN
Phone: 901 313 4485
Skype: SJO0923
AIM/Yahoo: simonjoliver
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Instances don't show up in Monitor and URLs do not work.
Dennis - In my experience FQDN is definitely the way to go - make sure your apps, monitor, and wotaskd all have the exact same thing. Run nslookup or similar at the command line to make sure the name resolves to the IP address of the NIC on the box, and the IP address resolves back to the name that you're using as the WOHost parameter. A handful of additional thoughts: 1) have you made sure that your adaptor config correctly has the correct hostnames and ports for the wotaskd(s) it needs to know about? What does the adaptor config page tell you about what apache thinks the world looks like? (Apologies if you already covered that... I just caught the last couple of posts). 2) have you checked your launchd boot scripts for wotaskd and monitor (if that's how you are launching them) to make sure that you don't have alternative WOHost entries in there as command line arguments? (if they aren't there already, maybe try adding them there, to make sure that the values you want are getting picked up). 3) I had an issue today (and I noticed someone else post something similar recently in connection with SSD boot drives) that wotaskd and womonitor were binding to the loopback address (only) not the ones I was asking them to - apparently because the nics weren't properly initialized at the time the apps were starting up at boot time. For me, killing the two java processes manually and allowing launchd to restart them fixed the problem. They came back up on the correct interfaces, and the IP's matched what they were expecting, and all was good. Have you tried manually killing/restarting the processes after the machine has booted up? 4) FWIW, I generally specify the WOHost for my apps as an additional command line argument in the app config in WOMonitor, rather than in the properties file. You may want to try that. I know from experience how frustrating the dance is to get things to work right, but it's generally always worked out for me, and I am deploying apps on Lion Server just fine, with the Wonder versions of monitor and wotaskd. Regards, Simon On Feb 28, 2012, at 3:26 PM, Gaastra Dennis - WO Lists wrote: Hi Tim, Thanks for your email. Yes DNS works correctly with 'changeip -checkhostname'; put full host names in wotask and JavaMonitor Properties files; and still nothing works. This is the most frustrating part of WO on Lion Server, however, this has always just worked for us in the past. Greetings, Dennis. -- Simon J. Oliver MA (Cantab.) CISSP-ISSAP, ISSMP, GWAPT, OSWP Information, Architecture Data Security Consultant Applied Information Technology Center/SBBER University of Memphis, TN Phone: 901 313 4485 Skype: SJO0923 AIM/Yahoo: simonjoliver ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: JavaMonitor wotask SSD Problem.
I saw this problem (or something very much like it) today on a 2008 Mac Pro running Leopard, and not an SSD in sight... so while SSD's make it worse, it can happen in other circumstances. In what seems to me like an odd decision, given Apple's dependency on it (and hyping of it) launchd doesn't enforce dependencies. The best solution is probably that rather than launching wotaskd and womonitor directly from the launchd plist, instead call a shell script that first checks that the NICs are up, and then launches wotaskd and monitor for you. That shell script can use 'ipconfig waitall' to block until the NICs are up. I haven't done it for WO yet, but I use something similar to set up static routes on my boxes at launch time. Based on that chnk of code (which started life as http://www.macosxhints.com/article.php?story=20060329085850170 , in the routing context) , I *think* that something like this should work to start them up: #!/bin/sh # We need to trap on TERM signals, according to Apple's launchd docs: trap 'exit 1' 15 # Issue a log message so we know when we started syslog -s -l 1 WOMonitor_start: starting WOMonitor... # Use the ipconfig waitall command to wait for all the # interfaces to come up: ipconfig waitall # This is where we start WOMonitor put your WOMonitor startup command here with any command line args # Sleep for a while so Launchd won't think we never ran sleep 10 # Issue a log message so we'll know when we finished syslog -s -l 1 WOMonitor_start: Done. # Exit with a clean status exit 0 You should be able to launch that from launchd, instead of womonitor itself. Regards, Simon On Feb 28, 2012, at 4:11 PM, Gaastra Dennis - WO Lists wrote: Hi Ken, All java tasks start, but they all don't work. Please see excerpt. mm4:Logs admin$ ps -ax | grep java 131 ?? 0:05.28 /usr/bin/java -XX:NewSize=2m -Xmx64m -Xms32m -DWORootDirectory=/System -DWOLocalRootDirectory= -DWOUserDirectory=/ -DWOEnvClassPath= -DWOApplicationClass=com.webobjects.monitor.wotaskd.Application -DWOPlatform=MacOS -Dcom.webobjects.pid=131 -classpath WOBootstrap.jar com.webobjects._bootstrap.WOBootstrap -WOPort 1085 132 ?? 0:05.80 /usr/bin/java -XX:NewSize=2m -Xmx64m -Xms32m -DWORootDirectory=/System -DWOLocalRootDirectory= -DWOUserDirectory=/ -DWOEnvClassPath= -DWOApplicationClass=com.webobjects.monitor.application.Application -DWOPlatform=MacOS -Dcom.webobjects.pid=132 -classpath WOBootstrap.jar com.webobjects._bootstrap.WOBootstrap -WOPort 56789 298 ?? 0:02.28 /usr/bin/java -XX:NewSize=2m -Xmx64m -Xms32m -DWORootDirectory=/System -DWOLocalRootDirectory= -DWOUserDirectory=/Library/WebObjects/Deployment/wotaskd.woa -DWOEnvClassPath= -DWOApplicationClass=com.webappz.bizdav.Application -DWOPlatform=MacOS -Dcom.webobjects.pid=298 -Xms1024M -Xmx1024M -classpath WOBootstrap.jar com.webobjects._bootstrap.WOBootstrap -WOHost vds4.webappz.comhttp://vds4.webappz.com -WOPort 2003 -WOCachingEnabled YES -WODebuggingEnabled NO -WOOutputPath /Library/WebObjects/Logs/bizDAV_VDS/bizDAV_VDS-1 -WOAutoOpenInBrowser NO -WOAutoOpenClientApplication NO -WOLifebeatInterval 30 -WOLifebeatEnabled YES -WOLifebeatDestinationPort 1085 -WOAdaptor WODefaultAdaptor -WOWorkerThreadCount 8 -WOListenQueueSize 128 -WOWorkerThreadCountMin 16 -WOWorkerThreadCountMax 256 -NSProjectSearchPath () -WOSessionTimeOut 3600 -WOStatisticsPassword stats -WOApplicationName bizDAV_VDS -WOMonitorEnabled YES -WONoPause YES -bizDAV.variant VDS -WOFrameworksBaseURL /WebObjects/bizDAV.woa/Frameworks 450 ?? 0:02.24 /usr/bin/java -XX:NewSize=2m -Xmx64m -Xms32m -DWORootDirectory=/System -DWOLocalRootDirectory= -DWOUserDirectory=/Library/WebObjects/Deployment/wotaskd.woa -DWOEnvClassPath= -DWOApplicationClass=com.webappz.bizdav.Application -DWOPlatform=MacOS -Dcom.webobjects.pid=450 -Xms1024M -Xmx1024M -classpath WOBootstrap.jar com.webobjects._bootstrap.WOBootstrap -WOHost vds4.webappz.comhttp://vds4.webappz.com -WOPort 2004 -WOCachingEnabled YES -WODebuggingEnabled NO -WOOutputPath /Library/WebObjects/Logs/bizDAV_VDS/bizDAV_VDS-2 -WOAutoOpenInBrowser NO -WOAutoOpenClientApplication NO -WOLifebeatInterval 30 -WOLifebeatEnabled YES -WOLifebeatDestinationPort 1085 -WOAdaptor WODefaultAdaptor -WOWorkerThreadCount 8 -WOListenQueueSize 128 -WOWorkerThreadCountMin 16 -WOWorkerThreadCountMax 256 -NSProjectSearchPath () -WOSessionTimeOut 3600 -WOStatisticsPassword stats -WOApplicationName bizDAV_VDS -WOMonitorEnabled YES -WONoPause YES -bizDAV.variant VDS -WOFrameworksBaseURL /WebObjects/bizDAV.woa/Frameworks 518 ttys0000:00.00 grep java On 27/Feb/12 10:41 PM, ISHIMOTO Ken wrote: Hi, It looks we have a problem with JavaMonitor and wotask, that had to be fixed. I have seen this Problem now on several Machines, and found the problem, but think about a fix. Maybe the only way is to fix the Apps Javacode itself... Test Machine was OS X Lion OS X SnowLeopard
Re: Instances don't show up in Monitor and URLs do not work.
Dennis - In your apache config file you should be including a line similar to: Include /System/Library/WebObjects/Adaptors/Apache/apache.conf In that file that is referenced is where the apache adaptor gets configured: that's where you tell apache where to find the wotaskd's its talking to. Take a look at the WebObjectsConfig line in there, to see what it's trying to talk to. It should be something like: WebObjectsConfig http://hostname:1085 10 (I have localhost in there, and it seems to work - I'd try the FQDN in your case). Simon On Feb 28, 2012, at 8:24 PM, Gaastra Dennis - WO Lists wrote: Hi Simon et al, Thanks for your insightful response. Please see my comments inside: On 28/Feb/12 5:09 PM, Simon J Oliver (sjoliver) wrote: Dennis - In my experience FQDN is definitely the way to go - make sure your apps, monitor, and wotaskd all have the exact same thing. JavaMonitor: - In File Properties, we added a line: WOHost = vds4.webappz.comhttp://vds4.webappz.com - In its log, womonitor.log, we read back WOHost=vds4.webappz.com - also in the log, we see WOAdaptorURL=http://localhost/cgi-bin/WebObjects; is this wrong? wotaskd: - Resources, we added a line: WOHost = vds4.webappz.comhttp://vds4.webappz.com - In its log, womonitor.log, we read back WOHost=vds4.webappz.com - also in the log, we see WOAdaptorURL=http://localhost/cgi-bin/WebObjects; is this wrong? the appz: - we see that WOHost is added, when doing a ps -ax | grep java: 298 ?? 0:02.34 /usr/bin/java -XX:NewSize=2m -Xmx64m -Xms32m -DWORootDirectory=/System -DWOLocalRootDirectory= -DWOUserDirectory=/Library/WebObjects/Deployment/wotaskd.woa -DWOEnvClassPath= -DWOApplicationClass=com.webappz.bizdav.Application -DWOPlatform=MacOS -Dcom.webobjects.pid=298 -Xms1024M -Xmx1024M -classpath WOBootstrap.jar com.webobjects._bootstrap.WOBootstrap -WOHost vds4.webappz.comhttp://vds4.webappz.com -WOPort 2003 -WOCachingEnabled YES -WODebuggingEnabled NO -WOOutputPath /Library/WebObjects/Logs/bizDAV_VDS/bizDAV_VDS-1 -WOAutoOpenInBrowser NO -WOAutoOpenClientApplication NO -WOLifebeatInterval 30 -WOLifebeatEnabled YES -WOLifebeatDestinationPort 1085 -WOAdaptor WODefaultAdaptor -WOWorkerThreadCount 8 -WOListenQueueSize 128 -WOWorkerThreadCountMin 16 -WOWorkerThreadCountMax 256 -NSProjectSearchPath () -WOSessionTimeOut 3600 -WOStatisticsPassword stats -WOApplicationName bizDAV_VDS -WOMonitorEnabled YES -WONoPause YES -bizDAV.variant VDS -WOFrameworksBaseURL /WebObjects/bizDAV.woa/Frameworks Run nslookup or similar at the command line to make sure the name resolves to the IP address of the NIC on the box, and the IP address resolves back to the name that you're using as the WOHost parameter. bash-3.2# changeip -checkhostname Primary address = 10.5.1.204 Current HostName= vds4.webappz.comhttp://vds4.webappz.com DNS HostName= vds4.webappz.comhttp://vds4.webappz.com The names match. There is nothing to change. dirserv:success = success A handful of additional thoughts: 1) have you made sure that your adaptor config correctly has the correct hostnames and ports for the wotaskd(s) it needs to know about? What does the adaptor config page tell you about what apache thinks the world looks like? (Apologies if you already covered that... I just caught the last couple of posts). I am not quite sure about this; where these can be set? Doing http://vds4:1085/cgi-bin/WebObjects/wotaskd.woa/wa/woconfig shows: adaptorapplication name=bizDAV_VDS scheduler=ROUNDROBIN urlVersion=4instance id=1 port=2003 host=vds4.webappz.comhttp://vds4.webappz.com sendTimeout=300 recvTimeout=300 cnctTimeout=300/instance id=2 port=2004 host=vds4.webappz.comhttp://vds4.webappz.com sendTimeout=300 recvTimeout=300 cnctTimeout=300//application/adaptor 2) have you checked your launchd boot scripts for wotaskd and monitor (if that's how you are launching them) to make sure that you don't have alternative WOHost entries in there as command line arguments? (if they aren't there already, maybe try adding them there, to make sure that the values you want are getting picked up). Please see above, we set them in the Properties. 3) I had an issue today (and I noticed someone else post something similar recently in connection with SSD boot drives) that wotaskd and womonitor were binding to the loopback address (only) not the ones I was asking them to - apparently because the nics weren't properly initialized at the time the apps were starting up at boot time. Yes, that was us too; we only use SSDs for deployment. Restarting wotaskd and JavaMonitor still comes up with the famous The requested application was not found on this server. For me, killing the two java processes manually and allowing launchd to restart them fixed the problem. Exactly but still; The requested application was not found on this server. They came back up on the correct interfaces, and the IP's matched what they were expecting, and all
Re: Instances don't show up in Monitor and URLs do not work.
Actually, in my haste I was looking at the wrong version of the config file... I can confirm that I am using FQDN in the WebObjectsConfig line to make it work. On Feb 28, 2012, at 8:32 PM, Simon Oliver wrote: Dennis - In your apache config file you should be including a line similar to: Include /System/Library/WebObjects/Adaptors/Apache/apache.conf In that file that is referenced is where the apache adaptor gets configured: that's where you tell apache where to find the wotaskd's its talking to. Take a look at the WebObjectsConfig line in there, to see what it's trying to talk to. It should be something like: WebObjectsConfig http://hostname:1085 10 (I have localhost in there, and it seems to work - I'd try the FQDN in your case). Simon -- Simon J. Oliver MA (Cantab.) CISSP-ISSAP, ISSMP, GWAPT, OSWP Information, Architecture Data Security Consultant Applied Information Technology Center/SBBER University of Memphis, TN Phone: 901 313 4485 Skype: SJO0923 AIM/Yahoo: simonjoliver ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Instances don't show up in Monitor and URLs do not work.
Dennis - some further thoughts below On Feb 28, 2012, at 8:24 PM, Gaastra Dennis - WO Lists wrote: 1) have you made sure that your adaptor config correctly has the correct hostnames and ports for the wotaskd(s) it needs to know about? What does the adaptor config page tell you about what apache thinks the world looks like? (Apologies if you already covered that... I just caught the last couple of posts). I am not quite sure about this; where these can be set? As explained in more detail in my previous response, this stuff gets set in the Apache WO config file which typically lives somewhere like: /System/Library/WebObjects/Adaptors/Apache/apache.conf That file also allows you to set an adaptor info password, so that you can see what apache thinks are the available apps via a url along the lines of: http://webserver/cgi-bin/WebObjects/WOAdaptorInfo?user+password (The apache.conf explains this). If you look at that,you can see whether mod_webobjects is talking to your wotaskd. It sounds like it isn't. 2) have you checked your launchd boot scripts for wotaskd and monitor (if that's how you are launching them) to make sure that you don't have alternative WOHost entries in there as command line arguments? (if they aren't there already, maybe try adding them there, to make sure that the values you want are getting picked up). Please see above, we set them in the Properties. That's fine - my point was mostly just to double check that there isn't something set on the command line in the plist that's overriding what you think you have in the Properties. However, it sounds like you're running into the SSD/NIC issue in the first instance. Manually restarting the processes *might* be fixing that bit - but then if I had to guess I'd say that the apache.conf file has a problem that stops mod_webobjects talkign to wotaskd , so you still get the 'The requested application was not found on this server' error. 3) I had an issue today (and I noticed someone else post something similar recently in connection with SSD boot drives) that wotaskd and womonitor were binding to the loopback address (only) not the ones I was asking them to - apparently because the nics weren't properly initialized at the time the apps were starting up at boot time. Yes, that was us too; we only use SSDs for deployment. Restarting wotaskd and JavaMonitor still comes up with the famous The requested application was not found on this server. Once you've restarted them, compare what the wotaskd/woconfig thinks the situation is, compared to what the WOAdaptorInfo page thinks is going on. If the instances are running, and wotaskd sees them... then the focus should be on Apache, I think, as the source of your problems. For me, killing the two java processes manually and allowing launchd to restart them fixed the problem. Exactly but still; The requested application was not found on this server. They came back up on the correct interfaces, and the IP's matched what they were expecting, and all was good. Have you tried manually killing/restarting the processes after the machine has booted up? Yes; yes 4) FWIW, I generally specify the WOHost for my apps as an additional command line argument in the app config in WOMonitor, rather than in the properties file. You may want to try that. Tried that, it just showed up twice per instance that way, in the ps -ax | grep java; and did not help. Apparently, monitor added it already I know from experience how frustrating the dance is to get things to work right, but it's generally always worked out for me, and I am deploying apps on Lion Server just fine, with the Wonder versions of monitor and wotaskd. We also got the newest: _appserver _appserveradm 337112 20 Feb 17:44 mod_WebObjects.so That seems to be the version I'm using on Lion - same size at least. So why does this still not work; maybe I am missing something else? Thanks for any further help Dennis Regards, Simon -- With Kind Regards, Dennis Gaastra, WEBAPPZ® Systems, Inc. (+1) 604.921.1333 www.webappz.comhttp://www.webappz.com/ www.scheduleDS.comhttp://www.scheduleDS.com/ www.1tracker.comhttp://www.1tracker.com/ This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. WEBAPPZ Systems, Inc., 726 -
Re: Instances don't show up in Monitor and URLs do not work.
Glad to help; I don't know that it's Lion per se causing the start-up thing. My Lion servers have been fine, and as I mentioned in the other thread, I saw it today with Leopard :-) If you try the 'ipconfig waitall' thing, let me know if it solves the problem. Simon On Feb 28, 2012, at 8:51 PM, Gaastra Dennis - WO Lists wrote: Hi Simon, Yes, you are bang on! That did the trick for the classic error. Thanks. Is it true that Lion Server is more finicky so that we must do all these extra steps? Now back to that start-up issue... Thanks Dennis. On 28/Feb/12 6:45 PM, Simon J Oliver (sjoliver) wrote: Actually, in my haste I was looking at the wrong version of the config file... I can confirm that I am using FQDN in the WebObjectsConfig line to make it work. On Feb 28, 2012, at 8:32 PM, Simon Oliver wrote: Dennis - In your apache config file you should be including a line similar to: Include /System/Library/WebObjects/Adaptors/Apache/apache.conf In that file that is referenced is where the apache adaptor gets configured: that's where you tell apache where to find the wotaskd's its talking to. Take a look at the WebObjectsConfig line in there, to see what it's trying to talk to. It should be something like: WebObjectsConfig http://http:/hostname:1085 10 (I have localhost in there, and it seems to work - I'd try the FQDN in your case). Simon -- Simon J. Oliver MA (Cantab.) CISSP-ISSAP, ISSMP, GWAPT, OSWP Information, Architecture Data Security Consultant Applied Information Technology Center/SBBER University of Memphis, TN Phone: 901 313 4485 Skype: SJO0923 AIM/Yahoo: simonjoliver -- With Kind Regards, Dennis Gaastra, WEBAPPZ® Systems, Inc. (+1) 604.921.1333 www.webappz.comhttp://www.webappz.com/ www.scheduleDS.comhttp://www.scheduleDS.com/ www.1tracker.comhttp://www.1tracker.com/ This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. WEBAPPZ Systems, Inc., 726 - 1489 Marine Drive, West Vancouver, BC, CANADA V7T 1B8, www.webappz.comhttp://www.webappz.com/ -- Simon J. Oliver MA (Cantab.) CISSP-ISSAP, ISSMP, GWAPT, OSWP Information, Architecture Data Security Consultant Applied Information Technology Center/SBBER University of Memphis, TN Phone: 901 313 4485 Skype: SJO0923 AIM/Yahoo: simonjoliver ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
