Re: mod_fcgid license questions
On Dec 16, 2008, at 4:30 PM, Ruediger Pluem wrote: On 12/16/2008 10:08 PM, William A. Rowe, Jr. wrote: Chris Darroch wrote: pqf wrote: For the moment, though, I think we're just waiting for some feedback from other httpd developers and especially those with some experience of the Incubator process. I or someone else likely needs to draft and submit a proposal to the Incubator, for example, as a next step. Any thoughts here from other folks? I'd prefer that we simply sponsor this effort under the httpd PMC here at our project. We have to file an IP code clearance through the Incubator, but that's relatively simple (and a good part is finished already now that the appropriate paperwork is filed with the secretary). Does anyone feel that the addition of mod_fcgid should be driven through the incubator? Speaking first hand, it didn't resolve the shortcomings of lack of community behind mod_aspdotnet, and didn't really give mod_ftp the visibility it needed (and attracted once it graduated). So for most existing modules, I don't think it solves many of the problems we might or might not face here at httpd. +1. I see no need to put it in the incubator, except for the IP code clearance paperwork. So it seems that the above fast track through the incubator to do just that should be enough. Afterwards put it in trunk and lets see how we can 'merge' it with mod_proxy_fcgi. +1.
Re: Documentation
2008-12-18 01:09 ed ed-h...@s5h.net napisał(a): Does anyone know if the information at http://apr.apache.org/docs/apr/0.9 is available in a printable format for reading off paper? I generally find things easier to read like that. Or does anyone have know of a resource that's similar and easy to read? Doxygen supports many output formats: http://www.stack.nl/~dimitri/doxygen/output.html You can check out APR sources and manually generate documentation.
Re: [VOTE] Release Apache HTTP server 2.2.11
William A. Rowe, Jr. wrote .dsw+.dsp lets us provide everyone with a makefiles and Makefile.win that works ***everywhere***. If you insist on a GUI, there is one extra step for Visual Studio 2002 (.NET) - Visual Studio 2008 users. But would you like that we provide you a Visual Studio 2008 project that VS 2005 users can't even load - due to the fact that the MS VS team insists on breaking the project description layout on every successive release? As I said before, it's a non-trivial problem, and if you want to vent please be our guest, and vent at the source of the problem, not we. I think most of us already have an idea of the source of the problem, and so please don't treat it as just complaining. One of the good things of open source is that it gives people patience and an open mind. As someone pointed early, it's probably time to move forward. If we continue to seriously think Win32/64 as an important platform for Apache (which was part of the reasons that shaped httpd 2.0), the time to say goodbye to those old Microsoft C 1995/98 .dsp stuff seems to have come. Here we probably shouldn't say much on MS's self compatibility policies. The reality is not that ideal; Even VS 2008 project files need to co-exist with VS 2005 and prior (though upgrading is usually much better). So I wonder if there is a possibility to propose a vote (or any other method) in the near future to see how many people still intend to use VS 5/6 (or perhaps Win9x) to run their Apache servers, and whether most of us would like to get rid of those dinosaurs and move forward. (As made clear sometime earlier, Windows 2008 R2 will only have 64-bit versions. The clock is ticking;-) Bing
Re: [VOTE] Release Apache HTTP server 2.2.11
bing swen wrote: As made clear sometime earlier, Windows 2008 R2 will only have 64-bit versions. The clock is ticking Has built fine (with edits) from command line without visual studio, and .sln's won't be the sole mechanism as long as I have a veto; 1) MS needlessly introduces breaking changes into each successive VS product release in a vain attempt to lock-in and force-upgrade (e.g. the .vcproj formats, manifest etc etc), and 2) There's no way out of an .sln into a procedural makefile build. Not even cmake or msbuild, at least the last time I looked. It's lock-in, ergo it's locked out (as the sole resource). You are right, it's time to dump dsp/dsw but not because they will be replaced with vcproj/sln, although it would be nice to get there for all the reasons we discussed. Much like simplifying the 64 bit build (which you can already get out of APR, APR-util etc). Your last observation was fun... have you actually ran Microsoft Vista SP1 x64 edition on a collection of assorted hardware? As cool as it would be to replace 32 bit with only 64 bit binaries, there is a performance penalty and it will be years before this is robust enough for the vast majority. Notice 2008 Server R1 was released in 32 bits? Wouldn't have happened if the world was ready. Bill
Re: [VOTE] Release Apache HTTP server 2.2.11
Also note that the x64 versions of windows do run 32-bit binaries without a problem. I've been providing x64 binaries of httpd 2.2 because people want them. I've moved from running windows on my servers to running linux. Even an old 128mb, P3 800mhz will run linux + httpd without a hitch. I also like to see some nicer build stuff for windows. But if a change does happen (I'd like to see it in 2.3 rather than 2.2). As wrowe has pointed out to me in earlier discussions. The .net series of vs are horrible in upgrade/downgrade wise. It would be awsome to have a build platform thats cross platform like ant but for c(++) I'm not sure that exists though. Never look. As of now compiling x64 bit httpd binaries isn't easy. But it's doable. ~Jorge On Fri, Dec 19, 2008 at 9:01 PM, William A. Rowe, Jr. wr...@rowe-clan.netwrote: bing swen wrote: As made clear sometime earlier, Windows 2008 R2 will only have 64-bit versions. The clock is ticking Has built fine (with edits) from command line without visual studio, and .sln's won't be the sole mechanism as long as I have a veto; 1) MS needlessly introduces breaking changes into each successive VS product release in a vain attempt to lock-in and force-upgrade (e.g. the .vcproj formats, manifest etc etc), and 2) There's no way out of an .sln into a procedural makefile build. Not even cmake or msbuild, at least the last time I looked. It's lock-in, ergo it's locked out (as the sole resource). You are right, it's time to dump dsp/dsw but not because they will be replaced with vcproj/sln, although it would be nice to get there for all the reasons we discussed. Much like simplifying the 64 bit build (which you can already get out of APR, APR-util etc). Your last observation was fun... have you actually ran Microsoft Vista SP1 x64 edition on a collection of assorted hardware? As cool as it would be to replace 32 bit with only 64 bit binaries, there is a performance penalty and it will be years before this is robust enough for the vast majority. Notice 2008 Server R1 was released in 32 bits? Wouldn't have happened if the world was ready. Bill
Re: [VOTE] Release Apache HTTP server 2.2.11
Jorge Schrauwen wrote : It would be awsome to have a build platform thats cross platform like ant but for c(++) I'm not sure that exists though. Never look. As I have mentioned before, the CMake project seems to be what is needed in that situation, as this software, like autoconf, performs various configuration checks specified in a script file, and then generates a set of Makefile/Project files, depending on the target platform, Unix, Windows, or whatever. On Windows, it can generate project files for any MSVC version, starting from VC6 to VS 2008 (Win32 and Win64). It has very few dependencies, and seems to be used by large projects, notably KDE, and interestingly for the ASF, for the Windows build of PCRE. The PCRE's CMakeLists.txt is IMHO a good starting point to understand various points of interest for a powerful Windows build system for Apache, like configuration variables, dependencies handling, header file generation, dynamic libraries, and even installation generation. I can volunteer to port Apache 2 to a Cmake based build system for Windows, even though I can't guarantee I can get results very fast due to my current basic knowledge of Cmake, as well as _very_ basic knowledge of the Apache source code arborescence. If such a thing would be done, what would be in your opinion a good starting point in the Apache repository ? (2.3.0-alpha ? the current 2.2 branch ? trunk ?)
Re: [VOTE] Release Apache HTTP server 2.2.11
On Dec 19, 2008, at 12:16 PM, Jorge Schrauwen wrote: Also note that the x64 versions of windows do run 32-bit binaries without a problem. More bits is, of course, better but I agree that it does not always make sense to run 64bits, even on a 64bits capable platform. I've been providing x64 binaries of httpd 2.2 because people want them. I think that's typical of our mentality regarding projects and initiatives: those who can, do and if someone takes the initiative to have Apache compile and run on 64bits Windows (other than it doesn't work please make it work), we'll pay attention whether or not running this way is actually the best approach. S. -- Sander Temme scte...@apache.org PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Release Apache HTTP server 2.2.11
On Dec 19, 2008, at 1:14 PM, Marc Noirot wrote: If such a thing would be done, what would be in your opinion a good starting point in the Apache repository ? (2.3.0-alpha ? the current 2.2 branch ? trunk ?) Trunk. S. -- Sander Temme scte...@apache.org PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Release Apache HTTP server 2.2.11
Marc Noirot wrote: It has very few dependencies, and seems to be used by large projects, notably KDE, and interestingly for the ASF, for the Windows build of PCRE. The PCRE's CMakeLists.txt is IMHO a good starting point to understand various points of interest for a powerful Windows build system for Apache, like configuration variables, dependencies handling, header file generation, dynamic libraries, and even installation generation. Thanks for that pointer! Something to wrap my head around. I can volunteer to port Apache 2 to a Cmake based build system for Windows, even though I can't guarantee I can get results very fast due to my current basic knowledge of Cmake, as well as _very_ basic knowledge of the Apache source code arborescence. Keep in mind, if we go Cmake, we entirely go Cmake (unix, and windows). Kill all birds with one stone. If such a thing would be done, what would be in your opinion a good starting point in the Apache repository ? (2.3.0-alpha ? the current 2.2 branch ? trunk ?) Trunk, as Jorge pointed out, that's where the action is. It's effectively the same and better than 2.3.0-alpha which will fall out of sync pretty quickly. The next 2.3-alpha will come from trunk again.
Re: Need suggestions for adding tproxy support to mod_proxy
On Thu, Dec 18, 2008 at 2:34 AM, Graham Leggett minf...@sharp.fm wrote: Pranav Desai wrote: Yeah, the application changes are restricted to a few lines. I believe you mean the connect_backend() and not the proxy_connect module for the CONNECT method ? I did yes, sorry. If this can be made available to all the proxy modules in one go, it would be ideal. There are more changes than I thought there would be. Tproxy needs the CAP_NET_ADMIN capability for setting the setsockopt(). So it seems like I have to preserve the capabilities using prctl and then after the effective user changes to non-privileged, set the CAP_NET_ADMIN capability for that process. What I am not sure of is: * Whats the best place to keep the capabilities, since it would have to be done before it drops the privilege. * Would I have to add the capability for all processes that are created for handling requests ? Is there a better way to set the capabilities of all the spawned processes ? Thanks -- Pranav Regards, Graham --
Re: mod_fcgid license questions
pqf wrote: Sorry for the delay, I have track down all patches base on my ChangeLog ( I keep my mail archive), so here is my brief: Minor patches ...Ignore here, I attach a file to show every modification to every ChangeLog entry. (If anyone think any change is major, please let me know) On a quick skim-through, what looks like the only large patch here belongs to Nick Kew, who's also an active httpd committer. Major patches So, that mean there are other two people are involved. If that's all it is, that should be fairly simple. I guess I'll ask the list again what the next step should be ... a vote? Contacting these folks? Advice appreciated! Thanks, happy holidays to everyone. Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
