Re: UNIX MPMs [ot?]
Leif W wrote: > > My only concern is, if some people solved the puzzle externally, then > are there barriers which prevent them from getting the code committed? > > The Metux web pages (official and unofficial) seem to be works in > progress. There is a quote which indicates that at least the guy > running the unofficial site would like to see this in Apache some day. The ASF doesn't suffer from the "not coded here" mentality. Many of our successful projects and codebases have originally started life elsewhere. As far as I know, even though internal (to the ASF) development of perchild "languished", we did accept patches, etc. So if anyone had wanted to continue working on it, they could have done what countless other developers have done and submitted patches, etc... That's the start towards getting ASF commit privs, becoming a contributor, a PMC member and an ASF member. If Metux would like to donate the code to the ASF, then incubator.apache.org would be a good link to check out first. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "There 10 types of people: those who read binary and everyone else."
Re: UNIX MPMs [ot?]
"William A. Rowe, Jr." <[EMAIL PROTECTED]>; [EMAIL PROTECTED]:57 GMT-5 At 08:10 AM 2/10/2005, Leif W wrote: I'm just trying to understand where the breakdown is. A feature that people want, the lack of which spawns a sloppy slew of incompatible workarounds, but no one around to respond and code it or fix what's available. The strength of Apache was always *nix, so why abandon security on *nix for the sake of portability to Windows? What gives you the impression that this has anything to do with alternate ports? What gives you the impression that Apache 1.3 "had this right"? Alternate ports? Oh I don't know, just looking at the timeline, interest in one area dies and grows in another area. Effort spent on making portable versus secure was the initial argument presented to me, and I came here to ask and get a better understanding if that was really the case or not. As I said later, my consideration of the matter was that it might have been just coincidence, and that seems to be more in check with reality. Also, how are things like setuid/setgid and *nix file permissions versus ACLs handled in Windows, versus ACLs in Linux on ext3 versus reiserfs... those kinds of portability questions. If that's all tucked away neatly into the APR, then great. But I just wasn't sure. Also I'm not talking specifically of 1.3 here. Apache originally came from *nix? And 1.3 had this problem? Then, looking at the group as an entity from the point of view of the outsider, it could have fixed the problem before spreading the problem to other OSes. Looking at it from the interal side, it is a mere coincidence and people are offended if you imply anyone directed anyone to do anything. But being part of a large group, you must acknowledge how the group's actions appear to those outside as well as those inside. At least that is what I am beginning to understand from the discussion, and I had not thought it could have been such different views of the same events. You hit the nail on the head "A feature that people want" ... ... but apparently not badly enough to solve the puzzle? My only concern is, if some people solved the puzzle externally, then are there barriers which prevent them from getting the code committed? Would something such as the prevalent attitude that it's not important be an obstacle they have to contend with? It's one thing to say an issue is not vital to you. But that should not preclude the acknowledgement that it may be vital for someone else. The Apache Software Foundation puts together code that folks want to create, it doesn't put together code that folks want to have created for them. Rather than bemoan the fact that something doesn't exist/is broken/isn't complete enough, they are welcome in any ASF project to offer issue + solution to their own itch. At least, when that solution in in the form of ASF Licensed code. The Metux web pages (official and unofficial) seem to be works in progress. There is a quote which indicates that at least the guy running the unofficial site would like to see this in Apache some day. Maybe they're still in beta stages or itself abandonned? Seems to be copyright ASL v1.1 as of 2.0.48 patch, so that shouldn't be a problem. But what kind of effort would be involved getting it into Apache? With all these broken MPMs, what's one more? ;-) If only I could facilitate the process somehow, if not technically by virtue of code then financially by siphoning money from the companies and admins who need this module, and get it to the hands of the guys who are motivated to code it but can not do it because they need to choose commercial jobs to have food. If you are suggesting that "OtherBill should be fixing Perchild to support Linux users and not off supporting Win32 users", well then, bite me :) Heh, no. Even if Win32 isn't my primary choice, I am very much grateful to be able to use tools like Apache in Win32, which I originally learned to use in Linux, and worked with in FreeBSD. If I got stuck on some other cpu architecture or OS, I'd be happy if Apache and other tools were likewise portable. Eh, just saying, if someone has some solution, I'd just hope it's reviewed and feedback given to help it be committed. Perchild will be fixed the moment someone wants to invest the time to fix perchild. There is no obstacle, there is also no volunteer. And several folks out there, rather than fix Perchild, have set out to do their own thing instead to create such features. Nothing stopping them from offering their own solution out there, nothing stopping them from contributing here. And so it is as it should be. Ok. Well, I think that's all anyone can say about the topic. I'll leave it at that. Thanks to everyone who responded. Please do not take personal offense at my curiousity or potentially confrontational or unwise way of wording things. I am very grateful to have a tool like Apache and I try my best to volunte
Re: UNIX MPMs [ot?]
"Sander Striker" <[EMAIL PROTECTED]>; [EMAIL PROTECTED]:35 GMT-5 From: Leif W [mailto:[EMAIL PROTECTED] Sent: Thursday, February 10, 2005 3:10 PM things which might commonly be used in concert? Is there any "direction" given from "the top" of the Apache group in regards to what gets attention? No, there is not. The committers are free to work on what they want. Ok, just wasn't sure how the ASF worked, some combination of directed and volunteer effort or something. Not "do this or else" strict direction, but "please focus energy here if you can", a laidback direction. In the message on the suPHP list, it is implied that there is in general a mentality that security is not a priority Given the way we handle security issues I don't think this remark will hold water. That's quoted out of context. Security holes get prompt attention. I was referring specifically to security as presented by perchild, as noted in the parenthisized expression below which was part of the same sentence. Sorry if my wording misconstrued the point. (at least regarding setuid per request as perchild MPM would like to do), Apparently there are a lot of people with the itch, but nobody scratching it. [...] Well, we are volunteers you know ;). I'm sure you could find someone to work on perchild on a contract basis, making your itch (one of) the developers itch. Or even an external party who would submit patches. I'd be more than happy to scratch this itch, but I haven't the coding ability or speed, testing environment, resources or time right now. I'd do it for the fee of training me how to do it. :p I'll need to consult the reference manuals. If I had financial resources I'd use them to encourage itches like this to be scratched, because when admin get burnt out over a missing feature, I'd like to give back that enthusiasm and fun and peace of mind. Coding is hard work and people deserve something for the time, even if enjoyment of the coding effort is usually enough. FWIW, I try to payback to this specific in the only way I can, by helping on the users list, and occasionally try to submit simpler code to other projects. Well, what is vital depends on context. Apparently it isn't as vital, since 2.x is certainly used without this vital mpm. Agreed, it would be very nice to see perchild development picked up again. Or metux integrated in the main distro (it'd need review and all that, and ofcourse desire from the metux developers to do so). For me personally, it isn't a big enough itch to start scratching it. Proxy and caching are a lot higher on my personal agenda. As are some other features I still am desperately seeking the time for to work on. There may be a discrepancy between what developers in general consensus think is vital, what is vital to individual developers, what admin think is vital, or people of different platforms, or what combinations of technologies are being used in concert. I'm thinking vital in terms of a common problem which many experience, for whom various workarounds do not work that well. To that end I am just curious about what it takes to have something of that magnitude eventually committed. If no developers are currently interested in a topic, who reviews it? What if someone applies to be a developer and says this is vital to them and a portion of the user base? Wether RTC or CTR, some patches of a lesser magnitude (affecting only one module for instance) seem to fly right through, yet other patches hang around a long time. I am just curious if "status quo" vs. "who you know" plays any part in the process. If so then it has to be planned for and addressed by anyone attempting to make a contribution. I'm not so good figuring this stuff out, so that's why I ask. The problem is that you drag in the *nix vs Windows argument. Why do we need to bother with that at all? Hmm, sorry, I didn't even see that happening. I did not feel like I was requesting a discussion of the A vs. B, but it maybe opened the wrong door, and I'm sorry for that. I mentioned something about A and B, thought that it might be mistaken for an argument of pro A con B, and stated that I didn't wish to discuss it in that context, and hoped that would be enough. The initial discussion was presented to me as perchild mpm (security) vs winnt mpm (portability), so my initial thoughts were along that line. But as I indicated, I considered the possibility that it was just a coincidence of events, not a directed intent. If I say I prefer A to B, is that wrong? IMO no, because I did not ask anyone to agree, nor ask their opinion, nor tell anyone what to prefer. You don't have to talk about that then. :-) I am not arguing for or against an OS. I just mentioned the three as the OSes to which I have had access, and experience, and to which platform some 3rd party solutions to setuid/setgid (perorphan?) are available and some are not. Of course I'd like a po
Re: UNIX MPMs [ot?]
"Nick Kew" <[EMAIL PROTECTED]>; [EMAIL PROTECTED]:15 GMT-5 On Thursday 10 February 2005 14:10, Leif W wrote: Hi, sorry if this is off-topic, but I just want to make sure I understand this problem. Last month I read an email on another list (suPHP) in which someone was upset about the security of Apache 2.0.x with all file i/o and cgi being done by a single user, and the perchild MPM being broken. That's rather different. If you care *at all* about security, you won't be running PHP as a module. So suexec is a complete solution there. Does this idea extend to any other modules as well? Are they all insecure simply because of Apache's design? Is that where the security problem lies? The module code can not be run as a separate user with fewer privileges per request? Leif
Re: UNIX MPMs [ot?]
At 08:10 AM 2/10/2005, Leif W wrote: >I'm just trying to understand where the breakdown is. A feature that people >want, the lack of which spawns a sloppy slew of incompatible workarounds, but >no one around to respond and code it or fix what's available. The strength of >Apache was always *nix, so why abandon security on *nix for the sake of >portability to Windows? What gives you the impression that this has anything to do with alternate ports? What gives you the impression that Apache 1.3 "had this right"? You hit the nail on the head "A feature that people want" ... ... but apparently not badly enough to solve the puzzle? The Apache Software Foundation puts together code that folks want to create, it doesn't put together code that folks want to have created for them. Rather than bemoan the fact that something doesn't exist/is broken/isn't complete enough, they are welcome in any ASF project to offer issue + solution to their own itch. At least, when that solution in in the form of ASF Licensed code. >It's the natural impression given by first glance of the timeline of events, >not an accusation. Or is it just coincidence that someone (or many people) >lost interest in perchild and there's been noone to pick up the slack, and >other people just happened to want to increase portability to windows? Ding ding ding. Each developer has their own expertise(s) and scratches their own itch. There is no ombudsman who is saying "Oh, you can add that code, just as soon as you go mop up this code over here..." If you are suggesting that "OtherBill should be fixing Perchild to support Linux users and not off supporting Win32 users", well then, bite me :) Perchild will be fixed the moment someone wants to invest the time to fix perchild. There is no obstacle, there is also no volunteer. And several folks out there, rather than fix Perchild, have set out to do their own thing instead to create such features. Nothing stopping them from offering their own solution out there, nothing stopping them from contributing here. And so it is as it should be.
RE: UNIX MPMs [ot?]
> From: Leif W [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 10, 2005 3:10 PM [...] > It's already a huge list of workaround and compatibility and portability for > an admin could be a nightmare. I do not know if there are even more security > wrappers needed for other language modules. Can anyone add to the list some > things which might commonly be used in concert? Is there any "direction" > given > from "the top" of the Apache group in regards to what gets attention? No, there is not. The committers are free to work on what they want. > In the message on the suPHP list, it is implied that there is in general a > mentality that security is not a priority Given the way we handle security issues I don't think this remark will hold water. > (at least regarding setuid per request as perchild MPM would like to do), Apparently there are a lot of people with the itch, but nobody scratching it. > only competing with MS/IIS. Not even that. I mean, it's fun to watch our marketshare rise every month, but that's not what the ASF is all about. > I'm not implying anything, I don't know what to believe, so that's why I ask. > I'm just trying to understand where the breakdown is. A feature that people > want, the lack of which spawns a sloppy slew of incompatible workarounds, but > no one around to respond and code it or fix what's available. Well, we are volunteers you know ;). I'm sure you could find someone to work on perchild on a contract basis, making your itch (one of) the developers itch. Or even an external party who would submit patches. > The strength of Apache was always *nix, so why abandon security on *nix for > the sake of portability to Windows? There's more to it than just portability to Windows. > It's the natural impression given by first glance of the timeline of events, > not an accusation. Or is it just coincidence that someone (or many people) > lost interest in perchild and there's been noone to pick up the slack, Correct. > and other people just happened to want to increase portability to windows? Portability in general. But this is all contained in the APR project, on top of which httpd-2.x is built. Also people worked on a lot of other things during last year. Just look at the Changelog, the commit messages etc, to see what I mean. > I mean, I like having a windows port, because I can at least practice using > Apache somewhat, and it expands the development platform, but I won't ever, > ever, EVER run it on Windows in production, simply because I'd never run > Windows in production. Not all administrators are in a position where they can refuse to run Windows. > Except insofar as to show Windows users a shining example of free software, > and offer the idea of using an entire OS filled with shining examples of free > software engineering. > ;-) Toungue in cheek of course, with the ugly little problems such as this > code abandonment of vital features at the back of my mind. Well, what is vital depends on context. Apparently it isn't as vital, since 2.x is certainly used without this vital mpm. Agreed, it would be very nice to see perchild development picked up again. Or metux integrated in the main distro (it'd need review and all that, and ofcourse desire from the metux developers to do so). For me personally, it isn't a big enough itch to start scratching it. Proxy and caching are a lot higher on my personal agenda. As are some other features I still am desperately seeking the time for to work on. > I don't mean to > start an OS flame war, so please don't respond with that in mind. :-) If > other > people would like to use Windows, it takes nothing away from me, I'm just > stating opinion based on my own interaction and experience with Apache, Win, > and > *nix (Linux & FreeBSD). The problem is that you drag in the *nix vs Windows argument. Why do we need to bother with that at all? Sander
Re: UNIX MPMs [ot?]
On Thursday 10 February 2005 14:10, Leif W wrote: > Hi, sorry if this is off-topic, but I just want to make sure I > understand this problem. Last month I read an email on another list > (suPHP) in which someone was upset about the security of Apache 2.0.x > with all file i/o and cgi being done by a single user, and the perchild > MPM being broken. That's rather different. If you care *at all* about security, you won't be running PHP as a module. So suexec is a complete solution there. -- Nick Kew
Re: UNIX MPMs [ot?]
"Nick Kew" <[EMAIL PROTECTED]>; [EMAIL PROTECTED]:11 GMT-5 I agree the documentation should be better. Also we should properly document the perchild-like options, since that is frequently-requested. In the meantime, here's a list of things to look at if you want perchild-like: * Metux MPM * mod_ruid (Linux only) * fastcgi (CGI plus) * suexec (for CGI) Hi, sorry if this is off-topic, but I just want to make sure I understand this problem. Last month I read an email on another list (suPHP) in which someone was upset about the security of Apache 2.0.x with all file i/o and cgi being done by a single user, and the perchild MPM being broken. The frustration is that it is difficult, if not impossible (and potentially not even portable) to get all of these "workarounds" working together. And the clinching belief is that these should all be handled in the core of Apache, or with a working MPM. Here I post as complete a list I can think of including the new ones I see above. * cgiwrap * FastCGI * Metux MPM * mod_perl * mod_php * mod_ruid (Linux only) * suexec * suphp It's already a huge list of workaround and compatibility and portability for an admin could be a nightmare. I do not know if there are even more security wrappers needed for other language modules. Can anyone add to the list some things which might commonly be used in concert? Is there any "direction" given from "the top" of the Apache group in regards to what gets attention? In the message on the suPHP list, it is implied that there is in general a mentality that security is not a priority (at least regarding setuid per request as perchild MPM would like to do), only competing with MS/IIS. I'm not implying anything, I don't know what to believe, so that's why I ask. I'm just trying to understand where the breakdown is. A feature that people want, the lack of which spawns a sloppy slew of incompatible workarounds, but no one around to respond and code it or fix what's available. The strength of Apache was always *nix, so why abandon security on *nix for the sake of portability to Windows? It's the natural impression given by first glance of the timeline of events, not an accusation. Or is it just coincidence that someone (or many people) lost interest in perchild and there's been noone to pick up the slack, and other people just happened to want to increase portability to windows? I mean, I like having a windows port, because I can at least practice using Apache somewhat, and it expands the development platform, but I won't ever, ever, EVER run it on Windows in production, simply because I'd never run Windows in production. Except insofar as to show Windows users a shining example of free software, and offer the idea of using an entire OS filled with shining examples of free software engineering. ;-) Toungue in cheek of course, with the ugly little problems such as this code abandonment of vital features at the back of my mind. I don't mean to start an OS flame war, so please don't respond with that in mind. :-) If other people would like to use Windows, it takes nothing away from me, I'm just stating opinion based on my own interaction and experience with Apache, Win, and *nix (Linux & FreeBSD). Leif
