Hello Folks, After all the troubles people have had with Debian I realize that what I''ve done still isn''t enough for smooth sailing. I''m now going to hold back the 0.3.13.4 release in order to put an end to the Debian problem once and for all. I''m currently planning the following changes: 1) Specific documentation for Debian. Debian will become the only Unix distro that requires specific instructions. This should be a sign to all that maybe it''s not the one to use. 2) Large warnings that you need a compiler. Fair enough, that''s a deficiency all around. 3) The Rakefile will refuse to build if the extension does not build and print a more extensive warning. 4) The Rakefile will warn people running on Debian that they most likely have to install a lot more packages, pointing them at the instructions. 5) The mongrel_rails script will check itself to make sure extensions exist and refuse to run, again pointing people at Debian instructions if on that system. If after this I can''t reduce the number of people having problems on Debian then I''m going to publicly declare that I do not support Debian installs of Mongrel via RubyGems and that they should install via Debian packages and work with the package maintainer. If there are Debian people who like running Mongrel on their computers then I''d ask that you step up and help. The fact that I''m holding back a release out of frustration from one distro (that I actually use) is enough for me to not want to support it. I have had less trouble supporting windows than Debian, which is just insane. And again, before people get their panties in a bunch, this isn''t a personal insult to you if you use Debian. These are *tools* not religions. I use Operating Systems to get more interesting work done. If you take my hatred of your operating system as hatred for you then you are *not* understanding me at all. You are a fantastic individual and I like you. I hate that you use such a horrible distribution of Linux. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.railsmachine.com/ -- Need Mongrel support?
Hey, I run ubuntu on my laptop and debian on several servers. I''ve got a production box running mongrel and in the next few days I''m about to install a bunch of stuff to a dev box for another project, it''s got a clean install of debian stable. I''ve dealt with the package/dependency mess before and figured out all the missing stuff. I''m not a super linux guru, and I''m no debian zealot, just have medium admin skills and enough persistence to figure out why broken stuff is broken. I''d be happy to help contribute some docs. What do you need? Lists of packages or complete docs? //Gotten any other offers of help here? Oh yeah, I''m driving from Colorado to the west coast right now, so it would be a day or two before I could contribute anything. But IMO you should do 2,3,4,5 and then do the release without holding for 1. Let me know if you can use my assistance here, phil Zed Shaw wrote:> Hello Folks, > > After all the troubles people have had with Debian I realize that what > I''ve done still isn''t enough for smooth sailing. I''m now going to hold > back the 0.3.13.4 release in order to put an end to the Debian problem > once and for all. > > I''m currently planning the following changes: > > 1) Specific documentation for Debian. Debian will become the only Unix > distro that requires specific instructions. This should be a sign to > all that maybe it''s not the one to use. > 2) Large warnings that you need a compiler. Fair enough, that''s a > deficiency all around. > 3) The Rakefile will refuse to build if the extension does not build and > print a more extensive warning. > 4) The Rakefile will warn people running on Debian that they most likely > have to install a lot more packages, pointing them at the instructions. > 5) The mongrel_rails script will check itself to make sure extensions > exist and refuse to run, again pointing people at Debian instructions if > on that system. > > If after this I can''t reduce the number of people having problems on > Debian then I''m going to publicly declare that I do not support Debian > installs of Mongrel via RubyGems and that they should install via Debian > packages and work with the package maintainer. > > If there are Debian people who like running Mongrel on their computers > then I''d ask that you step up and help. The fact that I''m holding back > a release out of frustration from one distro (that I actually use) is > enough for me to not want to support it. I have had less trouble > supporting windows than Debian, which is just insane. > > And again, before people get their panties in a bunch, this isn''t a > personal insult to you if you use Debian. These are *tools* not > religions. I use Operating Systems to get more interesting work done. > If you take my hatred of your operating system as hatred for you then > you are *not* understanding me at all. > > You are a fantastic individual and I like you. I hate that you use such > a horrible distribution of Linux. > >-- Phillip Kast (909)630-9562 phil at unimedia.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060720/db61c1eb/attachment.html
On 7/20/06, Zed Shaw <zedshaw at zedshaw.com> wrote:> After all the troubles people have had with Debian I realize that what > I''ve done still isn''t enough for smooth sailing. I''m now going to hold > back the 0.3.13.4 release in order to put an end to the Debian problem > once and for all.I''m wondering if it wouldn''t be easier to add a script before the gem build which, if the user is running a Debian-style distro, checks for the existence of the appropriate packages and prompts the user if they wouldn''t perhaps like to install them first? Maybe even actually install them for the user? I realize this is a strange thing to do in a gem pre-install, but it seems that the threshold for Debian-specific action has been passed, and it seems like automating the hell out of getting Debian to work is a better solution than giving people information up front, especially when it boils down to the important part: freeing up your time for actual work, not answering the same questions over and over again. I figure it''s time to get a bit more hand-holdy. To sweeten the deal, I''ve even written this pre-install script for you (and also to make sure I wasn''t asking you to do something for an annoying edge case which involves a lot of work). I''ve attached it. I''m not sure if the list of required packages is correct, though. -- Coda Hale http://blog.codahale.com -------------- next part -------------- A non-text attachment was scrubbed... Name: deb_preinstall_madness.rb Type: application/octet-stream Size: 1110 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20060720/a8b69fd7/attachment.obj
On Thu, 2006-07-20 at 12:20 -0600, Phillip Kast wrote:> Hey, > > I run ubuntu on my laptop and debian on several servers. I''ve got a > production box running mongrel and in the next few days I''m about to > install a bunch of stuff to a dev box for another project, it''s got a > clean install of debian stable. > > I''ve dealt with the package/dependency mess before and figured out all > the missing stuff. I''m not a super linux guru, and I''m no debian > zealot, just have medium admin skills and enough persistence to figure > out why broken stuff is broken. I''d be happy to help contribute some > docs. What do you need? Lists of packages or complete docs? Gotten any > other offers of help here? >Philip, documentation would be awesome. Basically read: http://mongrel.rubyforge.org/docs/contrib.html To get started writing docs (it''s like the doc writer''s dev guide), and then grab a fresh install of ubuntu and do the mongrel install from scratch. The way I like instructions is the "cut-paste" style where the user can paste the commands into the window and the stuff will work. Kind of like an annotated automation script.> Oh yeah, I''m driving from Colorado to the west coast right now, so it > would be a day or two before I could contribute anything. > But IMO you should do 2,3,4,5 and then do the release without holding > for 1.Take your time. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.railsmachine.com/ -- Need Mongrel support?
On 20 Jul 2006, at 18:39, Zed Shaw wrote:> Hello Folks, > > <snipped stuff> > > If there are Debian people who like running Mongrel on their computers > then I''d ask that you step up and help. The fact that I''m holding > back > a release out of frustration from one distro (that I actually use) is > enough for me to not want to support it. I have had less trouble > supporting windows than Debian, which is just insane. >Zed, my task for this evening is installing a mongrel stack on a almost spanking new Debian sarge install, taking notes as I go. I should be able to help with the docs. Plan is for ruby 1.8.4 from testing, mongrel from gems. I''ll let you know how it goes. Cheers, Chris (octopod on freenode)
On Thu, 2006-07-20 at 11:26 -0700, Coda Hale wrote:> On 7/20/06, Zed Shaw <zedshaw at zedshaw.com> wrote: > > After all the troubles people have had with Debian I realize that what > > I''ve done still isn''t enough for smooth sailing. I''m now going to hold > > back the 0.3.13.4 release in order to put an end to the Debian problem > > once and for all. > > I''m wondering if it wouldn''t be easier to add a script before the gem > build which, if the user is running a Debian-style distro, checks for > the existence of the appropriate packages and prompts the user if they > wouldn''t perhaps like to install them first? Maybe even actually > install them for the user? >Coda, problem is I''m not sure if gems support this. They don''t even support detecting that the extension build failed and stopping. If you got this script, and you know how it can be plugged in then I will love to have it.> To sweeten the deal, I''ve even written this pre-install script for you > (and also to make sure I wasn''t asking you to do something for an > annoying edge case which involves a lot of work). I''ve attached it. > I''m not sure if the list of required packages is correct, though.It''s a start. Can you do a bit of research to see if there''s such a way to run this and then abort from a gem install mongrel command? That''s the key is we want users to see something like:> gem install mongrel** Oops, you''re on Debian. Checking if you''ve followed the instructions found at http://mongrel.rubyforge.org/docs/debian.html ... !! PACKAGES NOT FOUND ** Debian requires that you have the following packages installed before building Mongrel: blah blah blah !! ERROR. Aborting due to missing Debian packages. If your script can list the packages, and gems can run it, then that''s perfect. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.railsmachine.com/ -- Need Mongrel support?
I was at a Ruby users group last night with Chad Fowler - the topic was RubyGems. This is something that has been brought up before. It would take time, resources, manpower - it''s a big deal. Ideally, the gem could: 1) detect in needed native libs are present. 2) install them if not present, specific to the OS "sudo yum install blah, blah" if Fedora (SuSE too?) "sudo apt-get install blah, blah, blah, blah" if Debian-based "sudo pkg_add -r blah, blah" if BSD-based "sudo pacman -S blah, blah" if Arch Linux "sudo emerge blah, blah" if Gentoo "sudo ports install blah, blah" if OS X, or point to a binary package? and even some automated hack if Windows, or at least give a URL to locate the installer. That''s quite an undertaking. That''s how it _should_ work, but wow that would take a lot of time and energy to implement and maintain. Anyway, the RubyGems guys are aware of this idea already. Another idea is "gem install mongrel" - what if it detected which build to use (ruby or win32) based on the Ruby install that''s running the gem command and just installed the latest one automatically? More food for thought. http://rubyforge.org/projects/rubygems/ On 7/20/06, Zed Shaw <zedshaw at zedshaw.com> wrote:> On Thu, 2006-07-20 at 11:26 -0700, Coda Hale wrote: > > On 7/20/06, Zed Shaw <zedshaw at zedshaw.com> wrote: > > > After all the troubles people have had with Debian I realize that what > > > I''ve done still isn''t enough for smooth sailing. I''m now going to hold > > > back the 0.3.13.4 release in order to put an end to the Debian problem > > > once and for all. > > > > I''m wondering if it wouldn''t be easier to add a script before the gem > > build which, if the user is running a Debian-style distro, checks for > > the existence of the appropriate packages and prompts the user if they > > wouldn''t perhaps like to install them first? Maybe even actually > > install them for the user? > > > > Coda, problem is I''m not sure if gems support this. They don''t even > support detecting that the extension build failed and stopping. If you > got this script, and you know how it can be plugged in then I will love > to have it. > > > To sweeten the deal, I''ve even written this pre-install script for you > > (and also to make sure I wasn''t asking you to do something for an > > annoying edge case which involves a lot of work). I''ve attached it. > > I''m not sure if the list of required packages is correct, though. > > It''s a start. Can you do a bit of research to see if there''s such a way > to run this and then abort from a gem install mongrel command? That''s > the key is we want users to see something like: > > > gem install mongrel > ** Oops, you''re on Debian. Checking if you''ve followed the instructions > found at http://mongrel.rubyforge.org/docs/debian.html ... > !! PACKAGES NOT FOUND > ** Debian requires that you have the following packages installed before > building Mongrel: > blah > blah > blah > !! ERROR. Aborting due to missing Debian packages. > > If your script can list the packages, and gems can run it, then that''s > perfect. > > > -- > Zed A. Shaw > http://www.zedshaw.com/ > http://mongrel.rubyforge.org/ > http://www.railsmachine.com/ -- Need Mongrel support? > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users >-- Cheers, Kevin
> -----Original Message----- > From: mongrel-users-bounces at rubyforge.org > [mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of Zed Shaw > Sent: Thursday, July 20, 2006 12:36 PM > To: mongrel-users at rubyforge.org > Subject: Re: [Mongrel] The Debian Plan<snip>> > I''m wondering if it wouldn''t be easier to add a script > before the gem > > build which, if the user is running a Debian-style distro, > checks for > > the existence of the appropriate packages and prompts the > user if they > > wouldn''t perhaps like to install them first? Maybe even actually > > install them for the user? > > > > Coda, problem is I''m not sure if gems support this. They > don''t even support detecting that the extension build failed > and stopping. If you got this script, and you know how it > can be plugged in then I will love to have it.I *think* the reason they don''t bail out on build failures is because they figure it''s up to you to bail out if you want using ''gem install -t''. If you were to add something to your gemspec that forced a bailout, yet the end user did ''gem install -f'', who wins? Mind you, I''m not advocating that the current behavior is good. Personally, I think gems should, by default, do what Perl''s CPAN does in the case of C extensions - bail out unless forced. In the meantime, I think I''ll add ''-run-tests'' to my gem config file, assuming this actually forces gems to bail out on failure (which I haven''t verified). Regards, Dan PS - There''s always RPA. This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
On 7/20/06, Zed Shaw <zedshaw at zedshaw.com> wrote:> Coda, problem is I''m not sure if gems support this. They don''t even > support detecting that the extension build failed and stopping. If you > got this script, and you know how it can be plugged in then I will love > to have it. > > It''s a start. Can you do a bit of research to see if there''s such a way > to run this and then abort from a gem install mongrel command?Any code added to the pre-config.rb file in the project root will be executed by setup.rb before the extension''s makefile is generated, thus heading the problems off at the pass. I''m pretty sure you can just rename the file I attached to pre-config.rb, toss it in the project, and once you get the required packages list filled out, you''re good to go. The output to the user for this would look like this: Mongrel requires the following Debian packages be installed: * build-essential * ruby1.8-dev Would you like to install these now? [y/n] n Installation canceled. No Mongrel for you. or Mongrel requires the following Debian packages be installed: * build-essential * ruby1.8-dev Would you like to install these now? [y/n] y Installing required packages... Password: (unless you''re running gem as root) (apt-get does its thing here) (mongrel goes on installing) That said, I don''t have much (read: any) experience with building Gems, so I''m not 100% positive this will work with gems (esp. with the changes to 0.9 regarding extension build output). If I could get a copy of the gemspec for Mongrel (or even be able to check out the SVN files or something) then I''d be willing to spend the time to dial this in perfectly. I''m like 99% sure this will work. It may be quicker for you to give it a shot (add some unrelated and unistalled package to the required list to see what it would look like). (Also, I have no idea what this does on Windows. Passing bash to cmd.exe may provoke a lot of ugly error messages for the user to worry about, so you may want to wrap the whole thing in an architecture check.) (Also, you may want to change the exit codes to something error-y.) -- Coda Hale http://blog.codahale.com
On 20/07/06, Zed Shaw <zedshaw at zedshaw.com> wrote:> If there are Debian people who like running Mongrel on their computers > then I''d ask that you step up and help.I''ve got no chance to write anything this weekend as I''m away, but I''ll contribute something next week. Cheers, -- Dave Murphy (Schwuk) http://schwuk.com
Hi, On Thu, Jul 20, 2006 at 01:39:21PM -0400, Zed Shaw wrote: [..]> I''m currently planning the following changes: > > 1) Specific documentation for Debian. Debian will become the only Unix > distro that requires specific instructions. This should be a sign to > all that maybe it''s not the one to use. > 2) Large warnings that you need a compiler. Fair enough, that''s a > deficiency all around. > 3) The Rakefile will refuse to build if the extension does not build and > print a more extensive warning. > 4) The Rakefile will warn people running on Debian that they most likely > have to install a lot more packages, pointing them at the instructions. > 5) The mongrel_rails script will check itself to make sure extensions > exist and refuse to run, again pointing people at Debian instructions if > on that system.that really should help. there''s no point in continuing the installation of the gem if the build of the native extension didn''t succeed - gem should just fail hard in that case, saying what''s missing.> If after this I can''t reduce the number of people having problems on > Debian then I''m going to publicly declare that I do not support Debian > installs of Mongrel via RubyGems and that they should install via Debian > packages and work with the package maintainer.Why not point people to the debs in the first place ? I''ll have new packages up as soon as 0.3.13.4 is out. Honestly, I consider compiling anything on a production system bad practice. Imho nobody running a Debian server should have to compile anything to get a new version of Mongrel installed. Once we get this right Debian is *the* Distro for running Mongrel without pain. Well, besides the fact it doesn''t have Apache 2.2 with it''s mod_proxy_balance, but that''s another story ;-) Jens -- webit! Gesellschaft f?r neue Medien mbH www.webit.de Dipl.-Wirtschaftsingenieur Jens Kr?mer kraemer at webit.de Schnorrstra?e 76 Tel +49 351 46766 0 D-01069 Dresden Fax +49 351 46766 66
On 20/07/06, Zed Shaw <zedshaw at zedshaw.com> wrote:> > > If there are Debian people who like running Mongrel on their computers > then I''d ask that you step up and help. The fact that I''m holding back > a release out of frustration from one distro (that I actually use) is > enough for me to not want to support it. I have had less trouble > supporting windows than Debian, which is just insane.Zed, I have written a capistrano based Debian machine builder which builds Debian based Virtual Machines automatically and sits them on top of Xen (it also builds the Xen controller automatically). The idea is to build machines internally for testing purposes and also to bring the Bytemark VM service ( www.bytemark.co.uk) up to a level where you can deploy Rails apps to the machine. Bytemark provide mirror support to both Rubyforge and Debian and they are just up the road from me. The idea was to have the RailsMachine gem deploy onto the base the tool built. But the lack of a Debian Apache 2.2 package has put the mockers on that. So (with extreme respect to the RailMachine crew) I''ve created an augmentation that is a little more flexible. It handles the automatic backporting of ruby 1.8.4 to Debian Stable and you can choose which release of Debian you want to use on each VM (other than the external Bytemark ones - which are always Sarge). Importantly it also knows all the dependencies required to run the various gems and packages required by Rails and mysql. I have a gem setup (vmbuilder), but I haven''t released anything yet because the tool is not quite production ready. There are a lot of holes in it (primarily the lack of an Apache 2.0/pound combination that saves backporting Apache 2.2), but the basic Mongrel/Ruby/Mysql system is fully operational. The documentation is also only half-way there - although its not much more than describing your machine requirements in either Ruby or YAML and then doing ''rake vm:setup''. If anybody would find this useful I''ll try and get the Gem up over the weekend. But please remember that it is very half-baked at the moment. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060721/b680a0f6/attachment.html
> > Mongrel requires the following Debian packages be installed: > * build-essential > * ruby1.8-dev > >Probably a dumb question, but what if the user didn''t install the ruby1.8-dev package but built ruby? Wouldn''t this check fail in that instance and block the installation? I don''t install any ruby packages on debian. I build ruby/gems and use gems as my package management. -- Andrew Stone -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060721/9c30d1a7/attachment.html
On Fri, 2006-07-21 at 12:26 +0200, Jens Kraemer wrote:> Hi, >> that really should help. there''s no point in continuing the installation > of the gem if the build of the native extension didn''t succeed - gem > should just fail hard in that case, saying what''s missing. > > > If after this I can''t reduce the number of people having problems on > > Debian then I''m going to publicly declare that I do not support Debian > > installs of Mongrel via RubyGems and that they should install via Debian > > packages and work with the package maintainer. > > Why not point people to the debs in the first place ? I''ll have new > packages up as soon as 0.3.13.4 is out. >Can you crank up a short e-mail of instructions for this and I''ll put it in the Debian uber doc I''m compiling? That''s basically what I''m saying in the "final option". Problem is people go *right* for rubygems, then go right to me when it doesn''t work. So I''ve got work to do. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.railsmachine.com/ -- Need Mongrel support?
> > I have written a capistrano based Debian machine builder which builds > Debian based Virtual Machines automatically and sits them on top of > Xen (it also builds the Xen controller automatically). The idea is to > build machines internally for testing purposes and also to bring the > Bytemark VM service ( www.bytemark.co.uk) up to a level where you can > deploy Rails apps to the machine. Bytemark provide mirror support to > both Rubyforge and Debian and they are just up the road from me.You should either get with the railsmachine folks and contribute back or you should setup a project page for it. I''m sure people would want it badly, just expect to do a lot more work to "productionize" it for other folks before their happy with it. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.railsmachine.com/ -- Need Mongrel support?
On 21 Jul 2006, at 14:58, Neil Wilson wrote:> > I have written a capistrano based Debian machine builder which > builds Debian based Virtual Machines automatically and sits them on > top of Xen (it also builds the Xen controller automatically). The > idea is to build machines internally for testing purposes and also > to bring the Bytemark VM service ( www.bytemark.co.uk) up to a > level where you can deploy Rails apps to the machine. Bytemark > provide mirror support to both Rubyforge and Debian and they are > just up the road from me. > > The idea was to have the RailsMachine gem deploy onto the base the > tool built. But the lack of a Debian Apache 2.2 package has put the > mockers on that. So (with extreme respect to the RailMachine crew) > I''ve created an augmentation that is a little more flexible. > > It handles the automatic backporting of ruby 1.8.4 to Debian Stable > and you can choose which release of Debian you want to use on each > VM (other than the external Bytemark ones - which are always > Sarge). Importantly it also knows all the dependencies required to > run the various gems and packages required by Rails and mysql. > > I have a gem setup (vmbuilder), but I haven''t released anything yet > because the tool is not quite production ready. There are a lot of > holes in it (primarily the lack of an Apache 2.0/pound combination > that saves backporting Apache 2.2), but the basic Mongrel/Ruby/ > Mysql system is fully operational. > > The documentation is also only half-way there - although its not > much more than describing your machine requirements in either Ruby > or YAML and then doing ''rake vm:setup''. > > If anybody would find this useful I''ll try and get the Gem up over > the weekend. But please remember that it is very half-baked at the > moment.Very cool! I''m going through this process manually at the moment, mainly to get to know the various bits of software I haven''t used before. I have a machine here I can reinstall Debian on over and over so let me know if you want help testing it out. Chers Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060721/0115a2ea/attachment.html
On 7/21/06, Andrew Stone <stonelists at gmail.com> wrote:> Probably a dumb question, but what if the user didn''t install the > ruby1.8-dev package but built ruby? Wouldn''t this check fail in that > instance and block the installation? > > I don''t install any ruby packages on debian. I build ruby/gems and use > gems as my package management.Not dumb at all, Andrew. Actually something I totally forgot to take into consideration. Thanks for bringing it up. I''ve re-written the script, and now the flow goes like this: If ruby1.8 is installed, check to see that build-essential and ruby1.8-dev are installed as well. If not, the user is prompted to install them. They have the option of declining, in which case they''re warned that the compile will in all likelihood explode, and are they sure they''d really like to do that? If ruby1.8 is not installed, we check to see that the ruby interpreter is installed (/usr/bin/env ruby, like the scripts), and prompt the user with a warning to make sure their Ruby header files are in the right place and goes on with the compile. If ruby1.8 isn''t installed and we can''t find the ruby interpreter, we''re off the maps so we let the user go ahead and sail off the edge of the earth. Whee! Now the only fixed exit point is when the installation of the required packages fails, which I think is a reasonable place to keel over dead. Also, it now checks to see that we''re not on Windows, so we don''t startle cmd.exe with all sorts of stderr redirection crazytalk. Zed--dropping this file in the Mongrel root directory (i.e., right next to setup.rb) will indeed get the jump on the rest of the installation process, including the extension building. Any exit within pre-config kills the entire setup process. Would various people mind running this and making sure I''m not forgetting something else? -- Coda Hale http://blog.codahale.com -------------- next part -------------- A non-text attachment was scrubbed... Name: pre-config.rb Type: application/octet-stream Size: 2212 bytes Desc: not available Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20060721/ef70d818/attachment.obj
Hi all, sorry for late reply. On Fri, Jul 21, 2006 at 12:04:36PM -0400, Zed Shaw wrote:> On Fri, 2006-07-21 at 12:26 +0200, Jens Kraemer wrote: > > Why not point people to the debs in the first place ? I''ll have new > > packages up as soon as 0.3.13.4 is out. > > Can you crank up a short e-mail of instructions for this and I''ll put it > in the Debian uber doc I''m compiling? That''s basically what I''m saying > in the "final option".Ok, so here''s a stripped down version of what I''ve written on my blog (http://www.jkraemer.net/articles/2006/07/07/mongrel-apache-and-rails-on-debian-sarge): Note: This assumes a clean Sarge install, things might get a bit difficult if there is an existing ruby / rubygems installation in /usr/local. ========== Install Ruby 1.8.4 + Mongrel =========== - add the following lines to /etc/apt/sources.list deb http://debian.jkraemer.net/apt sarge main contrib non-free deb http://ftp.de.debian.org/debian/ experimental main contrib - edit /etc/apt/preferences Package: * Pin: release a=experimental Pin-Priority: 100 - edit /etc/apt/apt.conf APT::Default-Release "stable"; - go get it, pen is completely optional apt-get update && apt-get install mongrel pen ========== Set up your Application =========== Apache 2.0/Pen/Mongrel - create config file for your app in /etc/mongrel/sites-enabled/ : # RAILS_ROOT of your application dir=/home/webapps/your_application/current # port the first mongrel instance should listen to, additional instances # will use ports above this port=8100 # number of mongrel instances servers=3 # port pen will listen on (if installed) proxy_port=8001 - fire up mongrel /etc/init.d/mongrel start - you should now have 3 mongrels running, listening on ports 8100-8102 - if installed, pen will be listening on port 8001, forwarding connections to the mongrels. - Rewrite rules for Apache 2.0 for forwarding to pen: RewriteEngine On RewriteRule ^/$ /index.html [QSA] RewriteRule ^([^.]+)$ $1.html [QSA] RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f # 8001 is the proxy_port from mongrel configuration of your app RewriteRule .* http://localhost:8001%{REQUEST_URI} [P,QSA] The experimental rubygems stuff is not that nice, but I didn''t manage to build a Sarge package for this until now. Maybe providing dummy Debian packages for people who have already installed Ruby and/or Rubygems from source would be a good idea, too. Jens -- webit! Gesellschaft f?r neue Medien mbH www.webit.de Dipl.-Wirtschaftsingenieur Jens Kr?mer kraemer at webit.de Schnorrstra?e 76 Tel +49 351 46766 0 D-01069 Dresden Fax +49 351 46766 66