On Thu, Jun 16, 2011 at 3:47 AM, Thomas Lundquist < thoma...@redpill-linpro.com> wrote:
> On Wed, Jun 15, 2011 at 10:12:42AM -0400, Jeremiah Dodds wrote: > > > Afaict, something along those lines will be a requirement, at least for > > development machines where people are editing code as a "normal" user, > and > > serving out of the directory they're working in (and not having apache or > > whatnot setup to serve out of that directory as their user). > > I would not have my main code set as www-data anyway, not dev, > nor production. > > > On a prod machine, I would guess that the console jobs would be run > rarely > > if ever. > > This notion puzzles me. I have never done any Symfony project that was > web frontend only. One was two frontends (REST/XML and administration) > and a set of console tasks and in another we use Gearman to help us > organize the background jobs. > > Having to be able to deal with console and web living together > also in production is definately not bikeshedding but a serious issue. > > I was a bit confused about people running (many) ./app/console jobs in production, the things I work on tend to be fairly self-contained, and maintenance scripts have no need of any of the default jobs (and I'm not familiar enough with that part of symfony2 to really take advantage of them myself yet). Bikeshedding was perhaps the wrong word -- I just meant that I've heard lots of people argue over minutia of how dev machines should be set up, to the point that it hinders actually getting anything done, when they aren't working on something where it actually matters what the setup is on the dev machine. The stuff I work on tends to be pretty agnostic about how it's set up on a dev machine, deployment gets handled by fabric or similar, and then prod machines aren't touched often other than for releases and when things break, which is hopefully not often. Then again, I've only really worked on sites that are pretty self-contained -- I'm not very familiar with strategies used for larger-scale deployments. Regardless, I wouldn't expect to run into this issue with permissions on a prod machine -- I'll have fleshed out users, groups, acls, sudoers entries, and whatever else I need on it. That said, don't expect everyone who's developing for a site or app to know anything about what setup would work well in production, nor do I think that they need to in all cases. On a dev machine, there's this deployment-dependent detail that leaks out to the person who's just trying to try out symfony, or fiddle around with ideas for a webapp, which (I'm assuming) is why a lot of frameworks provide a simple "fire up a server on localhost:8080 while you're developing, and then read this over here later when you want to put something out in the wild" type of job. If someone isn't going to be doing anything on anything but a local machine -- say they're still learning, or say they're an intern or whatever, why should they have to know anything about "apache runs as this user/group by default on your OS, but when you run a console job from a shell, the files you make end up not being writable by each other so you get permission errors"? I mean, for a lot of people, it's just a magic incantation to get symfony2 to work on their machine. They'll probably host with a company that supports symfony2 and handles that side of server setup when the time comes to go live, or learn about it when they need to. And yeah, saying "run this console job and go to localhost:8080" or whatnot is still a bit like magic incantations, but it's a nicely contained one, assuming it's done well. I'll be cleaning up the thing I wrote earlier tonight over the course of the next few days, and hopefully getting it to the point where it works with minor configuration for most apache installs, if only because I occasionally want to do a git clone on my own filesystem and host two branches at once, and it would provide a very quick way for doing so. -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
