Re: How to automatically start tomcat 5.5.9 under linux using local user
Greetings: I set tomcat 5.5.9 running in port 8080 so it can be started without using the root user. However, when I start tomcat using linux rc.local at system start up (/apps/tomcat-5/bin/startup.sh), it seems that the tomcat instance is started under root. Question: Where do i set the user that starts tomcat instance via Redhat Fedora Core start up? Thanks. BaTien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to automatically start tomcat 5.5.9 under linux using local user
Thanks. I will take a look at it. BaTien On Tue, 2005-08-16 at 20:31 +0100, Darryl L. Miles wrote: Duong BaTien wrote: I set tomcat 5.5.9 running in port 8080 so it can be started without using the root user. However, when I start tomcat using linux rc.local at system start up (/apps/tomcat-5/bin/startup.sh), it seems that the tomcat instance is started under root. Question: Where do i set the user that starts tomcat instance via Redhat Fedora Core start up? READ: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/setup.html Check out the -user username argument to jsvc which may not be so well documented. For non-root running check out jsvc bundled with Tomcat: Extracted TC to /opt/jakarta-tomcat-5.5.9 # To run it as java service need to build jsvc cd $CATALINA_HOME/bin tar -zxvf jsvc.tar.gz cd jsvc-src autoconf JAVA_HOME=/opt/jdk1.5.0_04 export JAVA_HOME sh ./configure make cp jsvc .. cd .. # Create a system user for tomcat /usr/sbin/groupadd -g 155 jakarta /usr/sbin/useradd -u 155 -g jakarta -s /sbin/nologin jakarta # Fix all the permissions on the $CATALINA_HOME with chown jakarta. -R $CATALINA_HOME # This bit below you can put into your own startup script for TC and call each time JAVA_HOME=/opt/jdk1.5.0_04 export JAVA_HOME PATH=$JAVA_HOME/bin:$PATH export PATH CATALINA_HOME=/opt/jakarta-tomcat-5.5.9 export CATALINA_HOME cd $CATALINA_HOME ./bin/jsvc -Djava.endorsed.dirs=./common/endorsed -cp ./bin/bootstrap.jar \ -outfile ./logs/catalina.out -errfile ./logs/catalina.err \ -pidfile ./logs/jsvc.pid \ -user jakarta \ org.apache.catalina.startup.Bootstrap Maybe you create a script in /etc/init.d/mytomcat that works the same way at the others in there ? Then symlink from each useful runlevel /etc/rc.d/rc[345].d/mytomcat - /etc/initd.d/mytomcat, use /sbin/runlevel to see which you are at already. Maybe you are lazy and simply add a few lines to /etc/rc.local ? Eitherway should do the trick. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problems with Fedora Core 4
On Mon, 2005-06-27 at 22:56 -0700, Paul Constantine wrote: Note: this is not meant to be a detailed bug report. I'm just fishing to see if anyone else is having some these problems. Hi, I'm a newbie on the list. I've used tomcat with Windows-IIS for about a year, and I just made the switch to Apache on Fedora Core 4. Tomcat 5 comes packaged with the FC4 distro, but it's using the GCJ jvm; I'm used to using Sun's jvm. A couple of issues: (1) It took me days to configure mod_jk to link Apache and Tomcat. The documentation sucks. I think I finally got it right after quite a bit of trial and error. (2) Now I can access the standard built-in webapps through something like http://localhost/jsp-examples/ without any problem. So I threw the JSPWiki.war into my webapps directory. It unpacked just fine, but when I tried to access it through http://localhost/JSPWiki/, I got a permission denied error. I'm quite certain that my permissions are set correctly. (3) I tried accessing it on the standard http connecter (i.e. http://localhost:8080/JSPWiki/) and I get 'WikiEngine not properly started' JasperException. (4) I also installed Sun's jvm and pointed Tomcat there, but now Tomcat won't work at all. I have successfully installed Fedora Core 4, tomcat 5.5.9 and the latest JspWiki. Everything works as expected under a very complex jsf system. Since all of my pages are dynamic (assembled from jsf + tiles), i just use tomcat and iptables to route port 80 - 8080, 443 - 8443. It's all very weird, but here's my theory. The permission denied error I'm getting when accessing it through Apache is really just a cover for the JasperException I'm getting through the http connector. The real problem might be that JSPWiki (and probably lots of other apps I want to use) won't work with the GCJ jvm. I'm thinking about uninstalling the packaged Tomcat 5 that came with FC4 and reinstalling it pointing at Sun's jvm. Yes, this may be a good idea. Using other poeple's pre-packages, you do not know what is going on. I generally take 1 package at a time and integrate them together. Has anyone else had experience using Tomcat 5 on FC4? Or have you had any problems similar to this? Yes, tomcat 5.5.9, FC4, and JspWiki are working fine together. Thanks in advance, Paul Constantine BaTien DBGROUPS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Force Non-SSL
Greetings: As promised, i report back my solutions and hope this may help others. On Mon, 2005-06-06 at 07:42 -0600, Duong BaTien wrote: On Mon, 2005-06-06 at 07:04 -0400, Tim Funk wrote: Almost. (I think) Thanks. I will try the workaround and report to the list for the benefits of others. BaTien DBGROUPS You can't request any pages under /WEB-INF. Security constraints are only for the incoming URL - not urls obtained by getRequestDispatcher() -Tim I know. These are my protected pages and i want to make sure that they must go through my presentation engine (Jsf + Tiles). BaTien Duong BaTien wrote: On Thu, 2005-05-26 at 06:34 -0400, Tim Funk wrote: From a config point of view no. The simple workaround - Ditch the web.xml config for requiring SSL - Create a filter which checks the scheme and URL - if the do not match what you desire - you can issue a redirect in the filter to https (or http) as desired -Tim Hello Tim and other tomcat 5.5.9 experts: If i understand you correctly, you propose: 1) set security constraint pages you want to run under ssl, such as: security-constraint web-resource-collection url-pattern/WEB-INF/secure/*/url-pattern http-methodPOST/http-method http-methodGET/http-method /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint 2) Write a servlet filter to direct any url NOT under the pattern /WEB-INF/secure/* to the same url such as /public/123.jsp. Do you have this code handy and want to share with others? The re direct must include both desired protocol and service port as explained in a proposed solution by Steve Ditlinger in his JavaWorld paper (Feb 2002) and later evolved into sslext for Struts. The approach is quite easy to implement for any framework. This is what we do under Jsf. The result will be: 1) When a user requests a /WEB-INF/secure/logonSuccess.jsp the container will force the user with its logon FORM, if the user is not authenticated. If username/password is authenticated the page logonSuccess.jsp wil be served. 2) If you create a user session (e.g. a guestTag for collecting user activities) while user is NOT authenticated, and the container now authenticated the user after the request of logonSuccess.jsp, the servlet spec will guarantee that the session visible to developer code after login be the same session object that was created prior to SSL login so there is no loss of session information. 3) Since the security model does not apply to RequestDispatcher according to serlet spec, the container will serve other requests under standard http and NOT https as reported after the user was served the logonSuccess.jsp. The desired protocol and service port must be explicitly specified for the requested page. Hope this may help and/or save others some time. BaTien DBGROUPS 4) Only after the user is authenticated by the server, we can use getUserPrincipal(), isUserInRole() to integrate container authentication with programmatic authorization. Before that, only a generic guestTag for recording user activities. Do i miss something? Thanks BaTien DBGROUPS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Force Non-SSL
On Mon, 2005-06-06 at 07:04 -0400, Tim Funk wrote: Almost. (I think) Thanks. I will try the workaround and report to the list for the benefits of others. BaTien DBGROUPS You can't request any pages under /WEB-INF. Security constraints are only for the incoming URL - not urls obtained by getRequestDispatcher() -Tim I know. These are my protected pages and i want to make sure that they must go through my presentation engine (Jsf + Tiles). BaTien Duong BaTien wrote: On Thu, 2005-05-26 at 06:34 -0400, Tim Funk wrote: From a config point of view no. The simple workaround - Ditch the web.xml config for requiring SSL - Create a filter which checks the scheme and URL - if the do not match what you desire - you can issue a redirect in the filter to https (or http) as desired -Tim Hello Tim and other tomcat 5.5.9 experts: If i understand you correctly, you propose: 1) set security constraint pages you want to run under ssl, such as: security-constraint web-resource-collection url-pattern/WEB-INF/secure/*/url-pattern http-methodPOST/http-method http-methodGET/http-method /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint 2) Write a servlet filter to direct any url NOT under the pattern /WEB-INF/secure/* to the same url such as /public/123.jsp. Do you have this code handy and want to share with others? The result will be: 1) When a user requests a /WEB-INF/secure/logonSuccess.jsp the container will force the user with its logon FORM, if the user is not authenticated. If username/password is authenticated the page logonSuccess.jsp wil be served. 2) If you create a user session (e.g. a guestTag for collecting user activities) while user is NOT authenticated, and the container now authenticated the user after the request of logonSuccess.jsp, the servlet spec will guarantee that the session visible to developer code after login be the same session object that was created prior to SSL login so there is no loss of session information. 3) Since the security model does not apply to RequestDispatcher according to serlet spec, the container will serve other requests under standard http and NOT https as reported after the user was served the logonSuccess.jsp. 4) Only after the user is authenticated by the server, we can use getUserPrincipal(), isUserInRole() to integrate container authentication with programmatic authorization. Before that, only a generic guestTag for recording user activities. Do i miss something? Thanks BaTien DBGROUPS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Force Non-SSL
On Thu, 2005-05-26 at 06:34 -0400, Tim Funk wrote: From a config point of view no. The simple workaround - Ditch the web.xml config for requiring SSL - Create a filter which checks the scheme and URL - if the do not match what you desire - you can issue a redirect in the filter to https (or http) as desired -Tim Hello Tim and other tomcat 5.5.9 experts: If i understand you correctly, you propose: 1) set security constraint pages you want to run under ssl, such as: security-constraint web-resource-collection url-pattern/WEB-INF/secure/*/url-pattern http-methodPOST/http-method http-methodGET/http-method /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint 2) Write a servlet filter to direct any url NOT under the pattern /WEB-INF/secure/* to the same url such as /public/123.jsp. Do you have this code handy and want to share with others? The result will be: 1) When a user requests a /WEB-INF/secure/logonSuccess.jsp the container will force the user with its logon FORM, if the user is not authenticated. If username/password is authenticated the page logonSuccess.jsp wil be served. 2) If you create a user session (e.g. a guestTag for collecting user activities) while user is NOT authenticated, and the container now authenticated the user after the request of logonSuccess.jsp, the servlet spec will guarantee that the session visible to developer code after login be the same session object that was created prior to SSL login so there is no loss of session information. 3) Since the security model does not apply to RequestDispatcher according to serlet spec, the container will serve other requests under standard http and NOT https as reported after the user was served the logonSuccess.jsp. 4) Only after the user is authenticated by the server, we can use getUserPrincipal(), isUserInRole() to integrate container authentication with programmatic authorization. Before that, only a generic guestTag for recording user activities. Do i miss something? Thanks BaTien DBGROUPS August Detlefsen wrote: Is there no way to do it? SSL creates a lot of overhead for a site that is serving up 100MB image files. --- Tim Funk [EMAIL PROTECTED] wrote: no -Tim August Detlefsen wrote: In my webapp I force clients to use SSL encryption for logins with a security constraint and transport-guarantee elements like this: security-constraint web-resource-collection web-resource-nameLogin/web-resource-name url-pattern/login/*/url-pattern /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint However, once a user hits the login page, every subsequent page also uses https. Is there a way to force them back to regular http once they leave the login section? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Running lots of virtual hosts on tomcat
Robbert-Jan Roos wrote: Hi, Our web department is thinking about moving from coldfusion to tomcat. Currently we have about 400 websites using apache's mod_vhost module. This works great. The only thing one needs to do is create a new directory www.bla.nl and the website is up and running. How would one do this in tomcat? I figured putting all the domainnames in server.xml is not an option since it would require restarting tomcat all the time. Using one Engine with a Context for each website seems more usable. Does anybody here have this kind of setup? Any pitfalls we might run into? Suggestions? Wow, you have a lot of websites. Portal may be an appropriate solution to consolidate contents. Description is in my previous post about Consolidate web applications. BaTien DBGROUPS Regards, Robbert-Jan Roos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Consolidate webapplications
Roland Carlsson wrote: Hi! We have a lot of small webservers running it's own special task, from router-admins to Outlook Web Access to the company public pages. All these servers is in a private network with one public ip. Today we have solved the problems with accessing these webservers from internet by assigning them different portnumbers but its hard for the users to remember what application is where. So, we are looking for a way to proxy our webserver into one portal that instead of using a filesystem can access other web-servers to get the pages for the users. What would be a good way of doing this? Is there any existing products for this scenario? Thanks in advance Roland Carlsson Hello Roland: We define portal as a web-based application that provides personalization, single signOn, and content aggregation from different sources. It hosts the presentation layer of a global Corporate Information System http://www.dbgroups.com/do/public/products/psi.do In this sense, it is an aggregation of a number of applications which are traditionally accessed via a url (either with different ports or different context). User can continue to use different url (either to applications, sites, departments, divisions, etc) but these urls are all pointed via DNS to the same portal site which has different welcome access points. Depending on the requested url, appropriate welcome page is presented via jsp forward mechanism. Each page in the portal can be configured which fragments it wants to be loaded to make up a portal page: meta description and keywords for search in the case of info pages, big picture to encapsulate the page in proper context, a small picture to actually describe the page, a complete site of the page owner (application, department, division, etc) such as the owner logo, menu, special offers, and copyright. Each application can be developed (or already existed) as a standard service or portlet application. This kind of portal will soon be demonstrated in http://myportal.myb2cb2b.com and delivered under existing standards. BaTien DBGROUPS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
