RT for crt.cs.wisc.edu
RT for crt.cs.wisc.edu
smime.p7s
|
|
| # | Tue Sep 09 13:46:44 2008 | agopu@indiana.edu - Ticket created | [Reply] | |||||||||||
Alain,Tim C/Scot (who I spoke to on the phone about this), Soichi needs some additional Apache modules for the OSG dashboard he's working on at the GOC. See emai below for details. Can you let us know what the protocol to add such modules into VDT ('s apache) are? Thanks very much! Cheers, Arvind Soichi's request: >> On 9/5/2008 9:51 AM, Soichi Hayashi pondered: >> >>> Tom, Arvind, >>> >>> I need a apache module mod_headers and mod_expires installed on apache >>> instance for RSV-WEB. What are the protocols involved with installing >>> new apache modules? Can you do this install, or do you want me to do it? >>> >>> Thanks, >>> For your reference, an email from our sysadmin Tom Lee who compiled it separately -- ideally we'd *not* like to do that. ... Which leaves finding the source for Apache 2.2.4 and compiling the modules ourselves as the least-bad solution. I don't even like doing this really, since we aren't using the same exact source code that was used to compile the VDT Apache (did they patch it, and would we know if they did?). At any rate, I have downloaded (from apache.org) and compiled Apache 2.2.4 on sonofsam. The source tarball is in /root/dl, and the build directory is /usr/src/httpd-2.2.4 . I installed things in /usr/src/httpd-2.2.4/install, because I have no intention that this Apache build will ever be used for anything other than reference. It might be good to just leave that build directory where it is, in fact -- if you need any of the many omitted modules, just copy them from there (they're in /usr/src/httpd-2.2.4/install/modules), and please don't change anything without letting people know. Here's my configure command for reference: [root@sonofsam httpd-2.2.4]# ./configure --prefix=/usr/src/httpd-2.2.4/install --enable-mods-shared=most |
||||||||||||||
| # | Tue Sep 09 14:51:18 2008 | roy - Taken | ||
| # | Tue Sep 09 14:56:33 2008 | roy - Correspondence added | [Reply] | |
|
On Tue Sep 09 13:46:44 2008, Arvind wrote: > Soichi needs some additional Apache modules for the OSG dashboard he's > working on at the GOC. See emai below for details. Can you let us know > what the protocol to add such modules into VDT ('s apache) are? Thanks > very much! The protocol is that you email vdt-support and ask us, then we ask you questions about it. :) Why do you need these modules? Will they benefit other VDT users, or just the GOC? How important are they? When do you need them by? In the past, I briefly talked to Soichi about this, and I think he said that the GOC is likely to need a steady stream of Apache modules. Do you see this kind of request recurring? Any idea of what you might need in the future? I think we're probably happy to provide them, but I need a deeper understanding of the situation. Thanks, -alain ----------------------------------------------------------------- Alain Roy vdt-support@opensciencegrid.org VDT Support http://vdt.cs.wisc.edu/support.html |
||||
| # | Tue Sep 09 14:56:34 2008 | RT_System - Status changed from 'new' to 'open' | ||
| # | Tue Sep 09 14:57:08 2008 | roy - Cc thomlee@indiana.edu added | ||
| # | Tue Sep 09 14:57:09 2008 | roy - Cc hayashis@indiana.edu added | ||
| # | Tue Sep 09 14:57:52 2008 | roy - Correspondence added | [Reply] | |
|
(Resending, because I forgot to add Soichi and Tom to the ticket.) On Tue Sep 09 13:46:44 2008, Arvind wrote: > Soichi needs some additional Apache modules for the OSG dashboard he's > working on at the GOC. See emai below for details. Can you let us know > what the protocol to add such modules into VDT ('s apache) are? Thanks > very much! The protocol is that you email vdt-support and ask us, then we ask you questions about it. :) Why do you need these modules? Will they benefit other VDT users, or just the GOC? How important are they? When do you need them by? In the past, I briefly talked to Soichi about this, and I think he said that the GOC is likely to need a steady stream of Apache modules. Do you see this kind of request recurring? Any idea of what you might need in the future? I think we're probably happy to provide them, but I need a deeper understanding of the situation. Thanks, -alain ----------------------------------------------------------------- Alain Roy vdt-support@opensciencegrid.org VDT Support http://vdt.cs.wisc.edu/support.html |
||||
| # | Wed Sep 10 10:13:46 2008 | hayashis@indiana.edu - Correspondence added | [Reply] | |||||||||||
The reason why I need mod_headers is to allow me to fine tune browser caching mechanism (such as "304 Not Modified" code) without making changes to the apache config file itself. This can dramatically increase the speed of page load. mod_expire is also for performance tuning purpose. I can't think of what other modules I will be needing in the future.. but I feel good to have all of the standard modules available just in case - it doesn't hurt anyone to have them in the /modules directory, right? Alain Roy via RT wrote: > (Resending, because I forgot to add Soichi and Tom to the ticket.) > > On Tue Sep 09 13:46:44 2008, Arvind wrote: > > >> Soichi needs some additional Apache modules for the OSG dashboard he's >>> working on at the GOC. See emai below for details. Can you let us know >> what the protocol to add such modules into VDT ('s apache) are? Thanks >> very much! >> > > The protocol is that you email vdt-support and ask us, then we ask you > questions about it. :) > > Why do you need these modules? Will they benefit other VDT users, or > just the GOC? How important are they? When do you need them by? > > In the past, I briefly talked to Soichi about this, and I think he said > that the GOC is likely to need a steady stream of Apache modules. Do you > see this kind of request recurring? Any idea of what you might need in > the future? > > I think we're probably happy to provide them, but I need a deeper > understanding of the situation. > > Thanks, > -alain > > ----------------------------------------------------------------- > Alain Roy vdt-support@opensciencegrid.org > VDT Support http://vdt.cs.wisc.edu/support.html > > > -- > View ticket at <http://crt.cs.wisc.edu/Ticket/Display.html?user=guest&pass=guest&id=3909> > VDT Support: vdt-support@opensciencegrid.org > |
||||||||||||||
| # | Wed Sep 10 10:23:10 2008 | roy - Correspondence added | [Reply] | |||||||||
On Sep 10, 2008, at 10:13 AM, Soichi Hayashi via RT wrote: > The reason why I need mod_headers is to allow me to fine tune browser > caching mechanism (such as "304 Not Modified" code) without making > changes to the apache config file itself. This can dramatically > increase > the speed of page load. mod_expire is also for performance tuning > purpose. Fair enough. By when do you need them to be in the VDT? We have to figure out how to prioritize this work. Do you think other sites might benefit from them being there? > I can't think of what other modules I will be needing in the future.. > but I feel good to have all of the standard modules available just in > case - it doesn't hurt anyone to have them in the /modules > directory, right? I would rather have things disabled than enabled if they aren't needed. It's generally safer to have less software, from a security perspective. -alain |
||||||||||||
| # | Wed Sep 10 10:43:39 2008 | hayashis@indiana.edu - Correspondence added | [Reply] | |||||||||||
Alain Roy via RT wrote: > On Sep 10, 2008, at 10:13 AM, Soichi Hayashi via RT wrote: I don't know what other sites are doing so I don't have specific site > >> The reason why I need mod_headers is to allow me to fine tune browser >>> caching mechanism (such as "304 Not Modified" code) without making >> changes to the apache config file itself. This can dramatically >> increase >> the speed of page load. mod_expire is also for performance tuning >> purpose. >> > Fair enough. By when do you need them to be in the VDT? We have to > figure out how to prioritize this work. > > Do you think other sites might benefit from them being there? > > names.. Having these modules there will allow sysadmins to not have to compile their own modules against the VDT apache - mod_python is used widely by people who uses Python based web application frameworks, and currently every site has to hack around to get it compiled against the VDT apache. >> I can't think of what other modules I will be needing in the future.. >>> but I feel good to have all of the standard modules available just in >> case - it doesn't hurt anyone to have them in the /modules >> directory, right? >> > I would rather have things disabled than enabled if they aren't > needed. It's generally safer to have less software, from a security > perspective. > > the them on apache instance. Sysadmin has to add LoadModule directive in apache configuration files for each modules to enable them. Having those modules sitting in that directory will have no negative impact. > -alain > > > -- > View ticket at <http://crt.cs.wisc.edu/Ticket/Display.html?user=guest&pass=guest&id=3909> > VDT Support: vdt-support@opensciencegrid.org > |
||||||||||||||
| # | Wed Sep 10 11:48:11 2008 | agopu@indiana.edu - Correspondence added | [Reply] | |||||||||||
On 9/10/2008 11:31 AM, Soichi Hayashi pondered: > Alain Roy via RT wrote: >> On Sep 10, 2008, at 10:13 AM, Soichi Hayashi via RT wrote: > I don't know what other sites are doing so I don't have specific site>> >>> The reason why I need mod_headers is to allow me to fine tune browser >>>>> caching mechanism (such as "304 Not Modified" code) without making >>> changes to the apache config file itself. This can dramatically >>> increase >>> the speed of page load. mod_expire is also for performance tuning >>> purpose. >>> >> Fair enough. By when do you need them to be in the VDT? We have to >> figure out how to prioritize this work. >> >> Do you think other sites might benefit from them being there? >> >> > names.. Having these modules there will allow sysadmins to not have to > compile their own modules against the VDT apache - mod_python is used > widely by people who uses Python based web application frameworks, and > currently every site has to hack around to get it compiled against the > VDT apache. > As an aside, I think the reason Alain et al have never received such requests is because most OSG admins use the VDT apache for the default purposes it's intended to server -- for example, perhaps as a scaffold for Tomcat to work in case of Gratia. I am guessing most folks use their own Apache to run their web services but in our case, we're trying to restrict the number of pieces of software our admin needs to maintain ... since we have the VDT Apache running on the machine, we are hoping we can use it for our other web services as well. Cheers, Arvind >>> I can't think of what other modules I will be needing in the future.. >>>>> but I feel good to have all of the standard modules available just in >>> case - it doesn't hurt anyone to have them in the /modules >>> directory, right? >>> >> I would rather have things disabled than enabled if they aren't >> needed. It's generally safer to have less software, from a security >> perspective. >> >> > enable the them on apache instance. Sysadmin has to add LoadModule > directive in apache configuration files for each modules to enable > them. Having those modules sitting in that directory will have no > negative impact. > >> -alain >>> >> >> -- >> View ticket at <http://crt.cs.wisc.edu/Ticket/Display.html?user=guest&pass=guest&id=3909> >> VDT Support: vdt-support@opensciencegrid.org >> |
||||||||||||||
| # | Fri Sep 12 14:30:45 2008 | roy - Priority changed from (no value) to '3' | ||
| # | Fri Sep 12 14:30:45 2008 | roy - Fix scheduled CUR added | ||
| # | Fri Sep 12 14:36:09 2008 | roy - Correspondence added | [Reply] | |||||||||
Sorry to drop out of the discussion, things got busy this week. Tim and I are looking into this, but it seems to be very straightforward to add mod_headers and mod_expires to our Apache build. One question: > I don't know what other sites are doing so I don't have specific site > names.. Having these modules there will allow sysadmins to not have to > compile their own modules against the VDT apache - mod_python is used > widely by people who uses Python based web application frameworks, and > currently every site has to hack around to get it compiled against the > VDT apache. I thought you were just asking for mod_headers and mod_expires. Are you also asking for mod_python? I haven't heard of any sites building mod_python: are sites beyond the GOC interested in it? Please set me straight, so we do the right thing here. >>> I can't think of what other modules I will be needing in the >>>>> future.. >>> but I feel good to have all of the standard modules available just >>> in >>> case - it doesn't hurt anyone to have them in the /modules >>> directory, right? >>> >> I would rather have things disabled than enabled if they aren't >> needed. It's generally safer to have less software, from a security >> perspective. >> >> > enable > the them on apache instance. Sysadmin has to add LoadModule > directive in > apache configuration files for each modules to enable them. Having > those > modules sitting in that directory will have no negative impact. In the big picture, it does matter. 1) It's not just technical. System administrators look at what we've installed. If we have something with a known security problem, even if it's not obviously used, it scares them. It's easier to convince someone that it's not a problem if it's not installed. 2) If there is a security problem with these modules, and if we're shipping them we have to ship the update because we don't know who is using them. That said, we're willing to ship mod_headers and mod_expires. -alain ----------------------------------------------------------------- Alain Roy vdt-support@opensciencegrid.org VDT Support http://vdt.cs.wisc.edu/support.html |
||||||||||||
| # | Mon Sep 15 14:22:37 2008 | cat - Subject changed from 'Requesting additional modules: mod_headers on VDT Apache' to 'Add modules to Apache build' | ||
| # | Thu Sep 18 10:54:51 2008 | hayashis@indiana.edu - Correspondence added | [Reply] | |||||||||||
If you could ship mod_headers and mod_expires, that will help us a lot - for now. In the future, if we need modules like mod_python, I will try to compile it myself. I am hoping that by the time we do that we will have updated version of VDT installed on our machines so that it will not be as hard to do. Thanks, Soichi Alain Roy via RT wrote: > Sorry to drop out of the discussion, things got busy this week. > > Tim and I are looking into this, but it seems to be very > straightforward to add mod_headers and mod_expires to our Apache > build. One question: > > >> I don't know what other sites are doing so I don't have specific site >>> names.. Having these modules there will allow sysadmins to not have to >> compile their own modules against the VDT apache - mod_python is used >> widely by people who uses Python based web application frameworks, and >> currently every site has to hack around to get it compiled against the >> VDT apache. >> > I thought you were just asking for mod_headers and mod_expires. Are > you also asking for mod_python? I haven't heard of any sites building > mod_python: are sites beyond the GOC interested in it? Please set me > straight, so we do the right thing here. > > >>>> I can't think of what other modules I will be needing in the >>> I would rather have things disabled than enabled if they aren't>>>> future.. >>>> but I feel good to have all of the standard modules available just >>>> in >>>> case - it doesn't hurt anyone to have them in the /modules >>>> directory, right? >>>> >>>> >>> needed. It's generally safer to have less software, from a security >>> perspective. >>> >>> >>> >> enable >> the them on apache instance. Sysadmin has to add LoadModule >> directive in >> apache configuration files for each modules to enable them. Having >> those >> modules sitting in that directory will have no negative impact. >> > In the big picture, it does matter. > > 1) It's not just technical. System administrators look at what we've > installed. If we have something with a known security problem, even if > it's not obviously used, it scares them. It's easier to convince > someone that it's not a problem if it's not installed. > > 2) If there is a security problem with these modules, and if we're > shipping them we have to ship the update because we don't know who is > using them. > > That said, we're willing to ship mod_headers and mod_expires. > > -alain > > ----------------------------------------------------------------- > Alain Roy vdt-support@opensciencegrid.org > VDT Support http://vdt.cs.wisc.edu/support.html > > > > -- > View ticket at <http://crt.cs.wisc.edu/Ticket/Display.html?user=guest&pass=guest&id=3909> > VDT Support: vdt-support@opensciencegrid.org > |
||||||||||||||
| # | Fri Sep 19 10:37:45 2008 | cat - Stolen from roy | ||
| # | Fri Sep 19 10:38:44 2008 | cat - Comments added | [Reply] | |||||||
Commit comment: Changed the Apache build to include mod_expires and mod_headers for the GOC. Changed files: U vdt/branches/vdt-1.10.1-cat-ramt-updates/Apache/nmi/build-apache.pl U vdt/branches/vdt-1.10.1-cat-ramt-updates/defs To generate a diff: svn diff -c 8050 file:///p/condor/workspaces/vdt/svn |
||||||||||
| # | Mon Sep 29 15:07:25 2008 | cat - Comments added | [Reply] | |||||||
Commit comment: Move LoadModule directives to VDT config file so that they're preserved (i.e., commented out or not) across updates. Changed files: U vdt/branches/vdt-1.10.1/Configure-Apache/vdt/setup/configure_apache To generate a diff: svn diff -c 8112 file:///p/vdt/workspace/svn |
||||||||||
| # | Mon Sep 29 15:33:57 2008 | cat - Comments added | [Reply] | |||||||
Commit comment: Darnit, forgot the 'm' option on regular expressions.... Changed files: U vdt/branches/vdt-1.10.1/Configure-Apache/vdt/setup/configure_apache To generate a diff: svn diff -c 8113 file:///p/vdt/workspace/svn |
||||||||||
| # | Tue Sep 30 16:44:45 2008 | cat - Correspondence added | [Reply] | |
|
We have added mod_expires and mod_headers to the VDT's Apache build and configuration (although disabled by default). We expect to release this update next Monday, October 6th. |
||||
| # | Tue Sep 30 16:45:07 2008 | cat - Status changed from 'open' to 'resolved' | ||
| # | Tue Sep 30 16:45:31 2008 | cat - Fixed in 1.10.1k added | ||
Time to display: 2.821719
»|« RT 3.8.2 Copyright 1996-2008 Best Practical Solutions, LLC.
