On Thu, Jun 16, 2011 at 06:02:08AM -0500, Jeremiah Dodds wrote: > 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).
I have added subscriptions and/or invoiceing to a few Symfony projects and they typically run as cronjobs (or "ordered" in a web frontend and sent to a Gearman queue). For me, being able to run most of the system both from CLI and web is a prerequisite for chossing it and it's also why Sf1's notion of validators in the forms felt totally useless to me. I need them in the object themselves so that all data entry points will be handled the same way. Sf2 seems to be able to handle that better but I have not had time to play enough with it to know if I'll be happy with it or not. If not, I know how to handle it anyway :=) Ohh, was that a digression? sorry, bad habit. > 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. For me when I started playing around with Sf2 it mattered, I did have issues with it and if it wasn't solvable I'd have to fine something else to play with. But it is. Somehow it still feels like a hack but as long as I can't really point at any hacks I can live with it. > 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. There are a few typical cases for production environment: Those set up by idiots, Those set up by developers. Those set up by real sysadmins Developers tend to copy their dev environment and sysadmins want to close down as much as possible. And we have to make bloody sure we don't end up with dissatisfied sysadmins, they usually have good reasons for being anal. They might also even not let you into the machines. (Which can make the console / cron thinge quite a challenge.) And I like the "./app console symfony:server" approach, there are more than enough daemons out there so that making our own is not needed. On the other hand, you can bet that quite a few will end up running that one in production, as one user, with everything owned by that user. Which is not really any good idea. Thomas. -- 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
