=== tritium_ is now known as tritium === Tweenaks is now known as Treenaks === Guest89320 is now known as Zic === jussio1 is now known as jussi01 === asac_ is now known as asac === Igorots is now known as Igorot === cjwatson_ is now known as cjwatson === cjwatson_ is now known as cjwatson [14:35] hi there ! [15:21] what time is the server meeting? [15:22] 16UTC? mmh oh then I must have missed it :( [15:22] 30 Dec 16:00: Server Team [15:22] Start: 2008-12-30 16:00 Timezone: Etc/GMT [15:22] kagou > and are we GMT+1 or +2? :] [15:22] @France [15:22] yann2, your are in France ? ^^ [15:22] kagou > yes :) [15:23] hrmm. no idea how that works :-P [15:23] @time [15:23] Current time in Etc/UTC: December 30 2008, 15:24:47 - Next meeting: Server Team in 35 minutes [15:23] +1 [15:23] @time France [15:23] mmh ok :) [15:23] Error: Unknown timezone: France - Full list: http://ubottu.com/timezones.html [15:23] @time Paris [15:23] @time Paris [15:23] Current time in Europe/Paris: December 30 2008, 16:25:05 - Next meeting: Server Team in 34 minutes [15:23] Current time in Europe/Paris: December 30 2008, 16:25:05 - Next meeting: Server Team in 34 minutes [15:23] \o/ [15:23] yes : [15:23] ok in half an hour then :) [15:23] :) [15:24] * persia doubts the server meeting will be held this week, but looks forward to it, just in case. [15:24] yeah I'm a bit unsure too :) === ubottu changed the topic of #ubuntu-meeting to: Current meeting: Server Team Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 30 Dec 17:00: Kernel Team | 31 Dec 16:00: Foundation Team | 31 Dec 17:00: QA Team | 01 Jan 12:00: Ubuntu Mobile Team | 01 Jan 14:00: Ubuntu Java [15:54] anyone? :] [16:01] \o/ [16:03] :'( [16:18] :) [16:19] as there is a ubuntu server meeting and it seems I am the only one attending I suggest that decisions should be taken by me :] [16:20] <[NikO]> o/ [16:24] yann2, There will likely be a real meeting next week. [16:24] persia > I know, it's alright :) just came to discuss about cgi's [16:24] https://wiki.ubuntu.com/ServerTeam/WebArchitecture [16:25] its likely to take ages to get anything improved so a week more or less [16:27] yann2, Doesn't that only require some MIRs? [16:27] MIRwhat? [16:27] Well, whichever things you want in main. [16:27] Main Inclusion Report [16:27] * persia looks for docs [16:27] well, fastcgi is not good enough to be in main [16:28] Well, then I'd think that'd be the first part to fix :) [16:29] Or find another way to run PHP fast and in separated processes [16:29] Or find another tool to write the code. [16:29] \o/ SPACE STATION \o/ [16:29] persia > yeah, that is all the issue :P [16:30] yann2, Does that need a meeting? I'd think it just needed coding. [16:31] well basically i wanted to know ubuntu's advice on using php in a safe way [16:31] yann2: well. don't? ;-) [16:31] :P [16:31] * Nafallo hides [16:32] idea is, make the point that there may be an issue (or learn how to do it properly if there is a way) and try to improve packaging and modules if there is not [16:32] Generally I've heard that PHP is hard to use safely. [16:32] yeah but it's quite a big issue :P [16:33] PHP apps aren't the safest [16:33] so if the install is not safe neither... [16:33] we don't want other locowebsites to be hacked to we? :P [16:33] I proposed throwing PHP out of Ubuntu some years ago... ;-) [16:34] we are trying to use fastcgi for both python and PHP [16:34] True, but I'd think that there are two ways forward: either suggest an alternate technology, or investigate why it isn't safe, and figure out why. [16:34] and we notice that python doesnt work 100% properly with fastcgi, and that fastcgi isn't exempt of bugs [16:34] persia > well I suggested fastcgi [16:34] but it needs attention :) [16:35] Safe Mode was removed in PHP 6.0.0. [16:35] Understood. I'm just not sure how a meeting helps that. [16:35] uhuh. wonder how php apps will be secure with php6... [16:36] persia > so how should I come up with the problem? [16:36] How do you mean? [16:36] if php6 removed safe mode if means there is no way (even ugly) to run php in an even slightly secure way [16:37] In that case, I'd suggest that PHP isn't the right tool to use. [16:37] that doesn't help me much :P and ubuntu.com is using php :) [16:39] Then the question to ask is: what needs to change to make PHP safe? [16:40] persia > well CGI with suexec makes it safe [16:40] mod_fastcgi makes it fast [16:41] And what's wrong with mod_fastcgi? [16:42] developped by a single guy, buggy, not properly documented, ... [16:42] So it needs help? [16:42] I am not a hardcore C developer :) [16:42] Are the bugs well documented? [16:42] basically I just wanted to see if people agreed that there was a problem, and start a discussion if it could be improved [16:43] https://bugs.launchpad.net/debian/+bug/162082 [16:43] Ubuntu bug 162082 in php5 "PHP fastcgi with PHP_FCGI_CHILDREN doesn't kill children when parent is killed" [Undecided,Confirmed] [16:43] fastcgi randomly looses children, which is pretty bad ;) [16:43] it also doesn't handle some EAGAIN signals from other bug reports I've seen, these people telling me it was important - but I don't know much about that other one [16:44] and ultimately, it's in universe [16:44] but, yeah, I don't hope to get this fixed anytime soon, so one week more or less :P [16:44] Well, converting from main to universe is trivial, if it's not buggy, so let's ignore that bit for now. [16:45] Still, I don't think a discussion in a meeting will help: it sounds like you need a developer to help track down and fix the bugs. [16:46] nah, I wanted to know if there was a secure way to run php, and if not, to get acknowledged that there was an issue and that it may get fixed at some point when a dev has time [16:46] at least that was the idea :P [16:46] Well, my understanding was that there were two classes of issues with PHP: firstly that it was hard to create a secure environment for it, and secondly that there were language features that encouraged insecure development practices. [16:46] but the first step is to agree that there is a problem, and the best way I thought to get this done was to raise it during a meeting [16:47] Mind you, either of these could be incorrect: it's just hearsay. [16:47] glad to hear I'm not the only one fighting with it :) [16:48] my very basic requirement is that if I am running two sites, one for A, and one for B, B doesn't get destroyed if A gets hacked [16:48] Well, I'd recommend rather putting it as an idea on brainstorm, and once you have a strong number of votes, and some more input on the correct solution, put together a spec. [16:48] It would get lost in a meeting, mostly. [16:49] as it would in brainstorm unless I start linking it everywhere... [16:49] it's a very technical issue so most people won't even know what it is [16:49] is there a brainstorm for ubuntu-server? [16:50] No, it's all the same brainstorm. Splitting it up into lots of little brainstorms would just make it even harder to track. [16:51] so you are saying brainstorm is the best way to report that type of issue? [16:52] Of the mechanisms available, yes. [16:52] Really, what you want to do is find a developer who wants PHP to be fast and secure, and get them to help out. [16:52] what's the meeting about then? :/ [16:52] pretty much :) [16:52] Tends to be status summary of work underway. [16:52] ok [16:53] If you want to identify new work, that's best done by getting something discussed at UDS. [16:53] maybe I can report this as a bug in launchpad [16:53] i know, but a/ the US are very far :) b/ I don't really agree with their immigration policies [16:53] But regardless, the key is really to get some developer interested, for which meetings tend not to be ideal mechanisms: meetings rather being used for developers to share their current activities. [16:54] I guess I'll have to wait for UDS to come over [16:54] Well, there's remote participation, as well. [16:56] bah. I'll open a launchpad bug, and maybe some day someone will realize how fucked up the situation really is :( [16:57] yann2, I think the fact that PHP isn't secure is widely disseminated. Whether it can be secure is an interesting question. [16:57] it is as secure as any other web app, if you want my advice. [16:57] That said, the trick is not to get someone to realise the issues with the current situation, but rather to get someone to want to make PHP work, rather than selecting something else when they discover PHP isn't secure. [16:57] CGI doesnt really make a difference if its PHP python or bash [16:58] Oh, I agree. I personally don't think CGI can be made secure. I think that needs a sandboxed application server system. [16:58] persia > disagree on this, it's even the usual way to do it. Open a bug, get people to confirm it, find an issue, get someone to fix it, patch it, test it, deploy :) [16:58] s/issue/solution [16:59] well ultimately you could chroot your fastcgi apps === ubottu changed the topic of #ubuntu-meeting to: Current meeting: Kernel Team Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 31 Dec 16:00: Foundation Team | 31 Dec 17:00: QA Team | 01 Jan 12:00: Ubuntu Mobile Team | 01 Jan 14:00: Ubuntu Java [16:59] which wouldnt make it 100% secure but a lot more secure :) [16:59] That's an interesting idea: it provides the sandbox. [17:00] file permissions can also provide a sandbox - kind of. [17:00] runnnig as a low privileged user is pretty much the same as using mod_php and www-data [17:00] Well, not really, because they application isn't restricted from accessing system files well. That's the current solution, isn't it? [17:01] yes [17:01] well, there is apparmor then... [17:02] never tried this on a webserver, i probably should [17:02] would need developping an apparmor profile, surely this could be made by the distro [17:03] Well, "by the distro" is mostly just by us, no? === cjwatson_ is now known as cjwatson [17:07] by the distro means it should be made easy to the final sysadmin, ie the sysadmin deploying shouldnt have to rewrite the rules every time [17:07] #312493 - some day.. maybe :) [17:08] Oh, I'd agree with that: I still think it needs someone to do it. [17:08] Fastest way to get it done is to investigate apparmor, write a draft profile, and get it included. [17:08] well to get apparmor you would need fastcgi first... [17:09] But fastcgi is already in Ubuntu, and likely compiled in an apparmor compatible way. [17:09] .. but it's in universe, buggy, and not sure about apparmor :) [17:10] Again, moving from universe to main is trivial. Also, I'm not sure the distinction will remain, based on the discussions on archive reorganisation. [17:10] you mean I would get support from canonical for universe? that'd be surprising [17:11] btw yeah you say it's trivial, but if it was in main I would use it at my company (I'm from the happy few with support :P) and expect them to fix the bugs - so it would mean quite a lot :) [17:12] longer term (1-2 years) I'd like to see ubuntu as a good web hosting distro, with a safe and fast way to run php/python apps by default and in a supported manner, with apparmor policy etc etc [17:12] Well, that presumes the not-quite-accurate assumption that "main" == "applications with support provided by Canonical". [17:12] gotta start somewhere :P [17:13] mh? [17:14] they can't be 100% involved in all the packages in main but at least my bug reports would draw attention to them right? :( [17:15] anyway - at least I am glad you agree the current setup isn't optimal, that's my first step :) [17:15] I don't know much about how Canonical support works, but I do know that the set of applications for which that support is provided doesn't match main, and that there was a bug about that, and it was fixed in intrepid. [17:16] There's now some gui that lets one identify which specific packages are supported. [17:16] Anyway, that's not really important. [17:16] The important part is that you've identified something that you consider a problem. [17:17] You've specifically identified three strategies that could help improve it: 1) fixing bugs in fastcgi, 2) chrooting individual websites (as opposed to the web server itself), and 3) creating an apparmor profiles. [17:18] Since you've said that you aren't yet proficient in C, I'd recommend concentrating on 3) for now, as that's likely most accessible without much C. [17:19] no wait it is *very* important to me :| [17:19] and I got support for hardy :x [17:20] actually I think the bug is important and affects many website [17:20] so I may spend some time trying to get a what-i-consider-to-be-secure appliance... [17:21] and document in a more wider form the issues , solutions, with proof o concepts, benches etc [17:21] it's a good two months of work but bah, someone gotta do it :( [17:21] That sounds like the right path. [17:22] I'm sure you'll end up with some suggested changes to the default configuration, and some patches as a result of that investigation. [17:22] I'm also fairly sure it shouldn't be very hard to get those applied to the packages in the repos so that nobody else has to repeat the work. [17:23] well it is going to be based on fastcgi which is lacking a lot of attention [17:23] but it's interesting work :) [17:24] Somehow I think that once you get started, and start publishing and sharing your results, you'll find like-minded people to help get the attention it needs. === ubottu changed the topic of #ubuntu-meeting to: Current meeting: Kernel Team Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 31 Dec 16:00: Foundation Team | 31 Dec 17:00: QA Team | 01 Jan 12:00: Ubuntu Mobile Team | 01 Jan 14:00: Ubuntu Java | 03 Jan 19:00: Kubuntu Developers === jussio1 is now known as jussi01 === mc44_ is now known as mc44 === ubottu changed the topic of #ubuntu-meeting to: Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 31 Dec 16:00: Foundation Team | 31 Dec 17:00: QA Team | 01 Jan 12:00: Ubuntu Mobile Team | 01 Jan 14:00: Ubuntu Java | 03 Jan 19:00: Kubuntu Developers | 05 Jan 20:00: EMEA Membership [19:04] bug 312493 [19:04] Launchpad bug 312493 in ubuntu "Not possible to run PHP in a multiuser and secure way" [Undecided,New] https://launchpad.net/bugs/312493 [19:31] nealmcb > comments and additional description to come soon ;) [19:35] yann2, persia: thanks for the server team meeting conversation. you should have done a "startmeeting" first though - makes it easier to record. No reason not to.... [19:35] nealmcb > it wasnt a meeting, really :) [19:36] but we should hae discussed on -server, ack and sorry for that [19:36] but it was a conversation that you'll want to refer the server team to - there are folks that would read it and provide feedback [19:37] nealmcb > i will add further descrpition to my wiki page and launchpad bug and refer server team people to it - I need some time to clarify my mind about what is technicaly posible [19:39] yann2: thanks - even better. persia asked good questions :) [19:39] i want to try fastcgi with apparmor and chroot first, see how it works and what it improves [19:39] and if I get it to work, write a doc how I did it, and study if it can be made easy enough for general purpose