Re: [Resin-interest] Resin 4 Configuration Sanity Check
To answer one part of your question: Additionally the application is started as root and for the app tier we use user and group to change the user. When we try to do the same thing in the web-loadbalancer tier the application fails to start. Is this normal/to be expected? Is it safe for the web-tier to be running as root? In a *nix environment, it is likely that non-root users are not allowed to bind ports 1024. That is, Resin cannot answer on HTTP (80) or HTTPS (443) request unless running as root. I'd recommend using port forwarding from 80/443 to some port 1024 and then run Resin as non-root. /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4 Configuration Sanity Check
Thanks Mattias I thought that the idea was that resin started as root in order to permit binding to the protected ports 1024 and subsequently switched to run as a different user. Our current setup with resin2 and a single server seems to do that. Thank you for taking the time to respond. Can anyone from caucho clarify this? Regards Alan On 28/09/2011 13:35, Mattias Jiderhamn wrote: To answer one part of your question: Additionally the application is started as root and for the app tier we useuser andgroup to change the user. When we try to do the same thing in the web-loadbalancer tier the application fails to start. Is this normal/to be expected? Is it safe for the web-tier to be running as root? In a *nix environment, it is likely that non-root users are not allowed to bind ports 1024. That is, Resin cannot answer on HTTP (80) or HTTPS (443) request unless running as root. I'd recommend using port forwarding from 80/443 to some port 1024 and then run Resin as non-root. /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest -- Alan Wright Athene Systems tel 0845 230 9803 Athene Systems Limited Registered Office: Shieling House Invincible Road Farnborough GU14 7QU Registered in England and Wales No. 3156080 ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Something interesting for People using Resin with Oracle
At the same time as upgrading to Resin 4 we are upgrading to Oracle 11gR2. Starting/stopping resin was very non-deterministic seeming to hang sometimes during application startup with references to connection timeouts in the error logs. SQLRecoverableException: IO Error: Connection reset The problem was traced to a drying up of the entropy poll preventing oracle jdbc from allocating connections until the pool was replenished The following article explains in full http://www.usn-it.de/index.php/2009/02/20/oracle-11g-jdbc-driver-hangs-blocked-by-devrandom-entropy-pool-empty The solution was to add the following to resin.xml Hope this helps someone. Alan -- Alan Wright Athene Systems tel 0845 230 9803 Athene Systems Limited Registered Office: Shieling House Invincible Road Farnborough GU14 7QU Registered in England and Wales No. 3156080 ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Something interesting for People using Resin with Oracle
On Wed, Sep 28, 2011 at 10:13, Alan Wright alan.wri...@athenesystems.com wrote: The solution was to add the following to resin.xml Add the following what? FC ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Something interesting for People using Resin with Oracle
At the same time as upgrading to Resin 4 we are upgrading to Oracle 11gR2. Starting/stopping resin was very non-deterministic seeming to hang sometimes during application startup with references to connection timeouts in the error logs. SQLRecoverableException: IO Error: Connection reset The problem was traced to a drying up of the entropy poll preventing oracle jdbc from allocating connections until the pool was replenished The following article explains in full http://www.usn-it.de/index.php/2009/02/20/oracle-11g-jdbc-driver-hangs-blocked-by-devrandom-entropy-pool-empty The solution was to add the following to resin.xml !-- Deal with problems associated with 11G JDBC driver new connection requires random number but generator uses entropy pool filled by random user actions - server has no connected user so entropy pool often empty -- jvm-arg-Djava.security.egd=file:///dev/urandom/jvm-arg Hope this helps someone. Alan -- Alan Wright Athene Systems tel 0845 230 9803 Athene Systems Limited Registered Office: Shieling House Invincible Road Farnborough GU14 7QU Registered in England and Wales No. 3156080 ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Something interesting for People using Resin with Oracle
Good to know Alan, thanks. Who would have thought servers accessing databases might be located in dedicated machines? Way to go, Oracle! :D S! D. El 28/09/2011 16:19, Alan Wright escribió: At the same time as upgrading to Resin 4 we are upgrading to Oracle 11gR2. Starting/stopping resin was very non-deterministic seeming to hang sometimes during application startup with references to connection timeouts in the error logs. SQLRecoverableException: IO Error: Connection reset The problem was traced to a drying up of the entropy poll preventing oracle jdbc from allocating connections until the pool was replenished The following article explains in full http://www.usn-it.de/index.php/2009/02/20/oracle-11g-jdbc-driver-hangs-blocked-by-devrandom-entropy-pool-empty The solution was to add the following to resin.xml !-- Deal with problems associated with 11G JDBC driver new connection requires random number but generator uses entropy pool filled by random user actions - server has no connected user so entropy pool often empty -- jvm-arg-Djava.security.egd=file:///dev/urandom/jvm-arg Hope this helps someone. Alan -- --- Daniel Lopez Janariz (d.lo...@uib.es) Web Services Centre for Information and Technology Balearic Islands University (SPAIN) --- ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4 Configuration Sanity Check
Hi Alan,
Given that Resin by default creates work and tmp directories in the
WEB-INF directory of each application, it might be risky to 3 instances
of the application fiddling with those files, so it might be better to
separate those directories per instance.
I haven't done so with 4.X so I can't offer you a complete sample
configuration file, but using:
temp-dir: http://caucho.com/resin-4.0/reference.xtp#tempdir
and
work-dir: http://caucho.com/resin-4.0/reference.xtp#workdir
along with the ${server.id} should do the trick.
You might want to do something similar with the log files to distinguish
between them, for example in Resin 3 we use something like:
log ...path=${resin.conf}/../../logs/resin-${server.id}.log ...
so we get a log file per server.
I hope it helps,
D.
---
Daniel Lopez Janariz (d.lo...@uib.es)
Web Services
Centre for Information and Technology
Balearic Islands University
(SPAIN)
---
El 28/09/2011 13:47, Alan Wright escribió:
Hi
...
Also each of the app-tier servers is pointing at the same webapp
directory since they are all on the same host. Is this OK or is it
dangerous?
...
Alan
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4 Configuration Sanity Check
On 09/28/2011 06:03 AM, Alan Wright wrote: Thanks Mattias I thought that the idea was that resin started as root in order to permit binding to the protected ports1024 and subsequently switched to run as a different user. Our current setup with resin2 and a single server seems to do that. Thank you for taking the time to respond. Can anyone from caucho clarify this? In Resin 4, the watchdog remains as root and the Resin instance starts as the specified user. There is never any switching of users in a single process; the switching happens during the Resin-instance spawning. If you have multiple Resin servers managed by the same watchdog and some of them need to bind to port 80, the watchdog needs to be started as root. You can use multiple watchdogs if you like, by using a server-default with a watchdog-port (or simply watchdog-port in the server.) resin ... cluster id=app-tier server-default watchdog-port6601/watchdog-port /server-default ... /cluster cluster id=web-tier server-default watchdog-port6600/watchdog-port /server-default ... /cluster -- Scott Regards Alan On 28/09/2011 13:35, Mattias Jiderhamn wrote: To answer one part of your question: Additionally the application is started as root and for the app tier we useuser andgroup to change the user. When we try to do the same thing in the web-loadbalancer tier the application fails to start. Is this normal/to be expected? Is it safe for the web-tier to be running as root? In a *nix environment, it is likely that non-root users are not allowed to bind ports 1024. That is, Resin cannot answer on HTTP (80) or HTTPS (443) request unless running as root. I'd recommend using port forwarding from 80/443 to some port 1024 and then run Resin as non-root. /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Using Google id's with Resin
On 09/25/2011 09:45 AM, Stargazer wrote: We have a Resin powered JEE app and are expanding it to work with Android. One of the cool things on Android is you know the user is logged into a Google account. With the Google App Engine, you can do more that just authenticate since they provide all the back end service data. For example, if I created a simple App Engine app which asked for the Google id and password, I could then say Hi John having pulled John as the real username, rather than the email address. I've also added this as a bug report at http://bugs.caucho.com/view.php?id=4780. At minimum, we should have a built-in open-id authenticator and login. -- Scott So to expand we can either (gulp) lose Resin and move entirely to the App Engine, which I really don't want to do, or replicate the authentication system Google uses, as in the simple example above, to do it on Resin (which is what I prefer). In other words I want to authenticate a valid Google user using Resin but never see the password. I see this issue as becoming more and more common, for example Google just opened the API for Google+, and a great use case for us is to be able to access a users circles from server side java. So as usual its over to you smarts on this list for ideas, or suggestions such as if I should be looking at some OpenId or whatever based system I can roll in ;-) Sincere thanks... ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4 Configuration Sanity Check
On 09/28/2011 04:47 AM, Alan Wright wrote: Hi I am migrating from resin 2 to 4.0.22 and have a single host configured with a web-loadbalance tier (1 server) and an application tier (3 servers). We have elected to do this for resilience and also to make adding hosts at a later date easier to implement. We start 3 servers on the app-tier to create a triad but it may be that we only really need 2 servers to get basic failover resilience. Is there any benefit from having a triad or am i just wasting resources with the overhead of loading the same application environment 3 times? Three might be overkill in your configuration. Statistically, it would give you a better resilience. A main scenario for the triad was a customer case where they took down servers periodically for maintenance and had a crash at the same time (this was before the triad or the hub-and-spoke model and with an 8-server cluster), and therefore some of their persistent sessions were lost. The three server triad gives you a backup, even when you take down a triad server deliberately. I don't think that scenario applies in your case. Another main reason is failover load. On a fully-loaded system, taking down (or crashing) one of three servers means the other two work 50% harder. If there were only two, it would be 100% which could cause a cascading failure. That scenario doesn't apply because your backup servers are using the same CPU, so you shouldn't have a cascading failure. In your case, since you only have the extra servers for reliability, and they're on the same machine, the third server isn't as important. -- Scott Also each of the app-tier servers is pointing at the same webapp directory since they are all on the same host. Is this OK or is it dangerous? Additionally the application is started as root and for the app tier we useuser andgroup to change the user. When we try to do the same thing in the web-loadbalancer tier the application fails to start. Is this normal/to be expected? Is it safe for the web-tier to be running as root? Thanks to those who have responded to my earlier queries. Alan ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
