Rails - Oct 2005 - SCGI Rails Runner 0.4.2 (Bug Fixes)

Hi Folks,

I''ve posted version 0.4.2 of SCGI Rails Runner (SRR) that fixes all of
the issues people reported to me with 0.4.1.  You can get this release
at:

	http://www.zedshaw.com/downloads/scgi_rails/

And read the announcement at:

	http://www.zedshaw.com/

== Fixes

This 0.4.2 release fixes the following problems:

- The gem now has dependency information for cmdparse and highline.
- Installing via gem will work even if the scripts are installed with
the wrong permissions.
- Production and Development mode should both work equally well and
have been tested in OSX (others with the problem should test too).
- You can now use the -M option to merge your old config with a new
option.  It was broken previously.


== Apache AJAX Bug People

People with the AJAX problem on Apache should download the latest
mod_scgi source from:

http://www.zedshaw.com/downloads/scgi_rails/scgi-ajax_fix.tar.bz2

This is a wget grab of the source at:

http://arctrix.com/nas/scgi/src/

Which is supposed to contain the correct source.  Hopefully the
mod_scgi author will publish an official release soon.


Zed A. Shaw
http://www.zedshaw.com/

On 10/18/05, Zed A. Shaw <zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org>
wrote:
>
> - You can now use the -M option to merge your old config with a new
> option. It was broken previously.

Will it work if internally in Instant Rails I just always use the -M option?
That is, will it still work correctly with -M when the old config
doesn''t
exist?

Curt


_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

Nope, you have to make a config first.  But, you could just create a
default setup for your instant rails install that has a config/scgi.yaml
file already there.  Then the -M all the time would work great.  You''d
then just have to watch for migration issues and such for later versions
of your setup.

Zed
> On 10/18/05, Zed A. Shaw
<zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org> wrote:
>>
>> - You can now use the -M option to merge your old config with a new
>> option. It was broken previously.
>
>
> Will it work if internally in Instant Rails I just always use the -M
> option?
> That is, will it still work correctly with -M when the old config
doesn''t
> exist?
>
> Curt
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

> I''ve posted version 0.4.2 of SCGI Rails Runner (SRR) that fixes
all of
> the issues people reported to me with 0.4.1.  You can get this release
> at:
>
>         http://www.zedshaw.com/downloads/scgi_rails/
I''ve tested version 0.4.2 and it seems to be working.  However, I did
notice that scgi_ctrl -v was still displaying 0.4.1.  Also, the
COPYING and LICENSE files have DHH as the copyright holder, was that
intentional?

Would it be possible to bring back single port clustering, at least as
an option (it worked for me with 0.3.1)?  I looked at the code, but
couldn''t see a simple solution that would work cleanly. Creating a
socket and then forking multiple times in SCGI::Controller#run before
calling SCGI::Processor#listen with the socket might work, but I''m
guessing that would break scgi_ctrl stop/restart/etc..  It looks like
scgi.rb is tightly coupled to DRb.  I preferred the simpler
children.yaml control mechanism in 0.3.1, any chance of bringing that
back as a option?  Also, is there a way to turn off the password
requests for scgi_ctrl stop/restart?  I''m not in a shared hosting
environment so I don''t see that it brings me any extra security.

Thanks again for your work on SCGI.

On Tue, 18 Oct 2005 11:18:05 -0700
Jeremy Evans <jeremyevans0-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> I''ve tested version 0.4.2 and it seems to be working.  However, I
did
> notice that scgi_ctrl -v was still displaying 0.4.1.  Also, the
> COPYING and LICENSE files have DHH as the copyright holder, was that
> intentional?
> 
DOH!  I like the guy but not that much.  :-)  It''s changed now on the
site.
> Would it be possible to bring back single port clustering, at least as
> an option (it worked for me with 0.3.1)?  I looked at the code, but
> couldn''t see a simple solution that would work cleanly. Creating a
> socket and then forking multiple times in SCGI::Controller#run before
> calling SCGI::Processor#listen with the socket might work, but I''m
> guessing that would break scgi_ctrl stop/restart/etc..  It looks like
> scgi.rb is tightly coupled to DRb.  I preferred the simpler
> children.yaml control mechanism in 0.3.1, any chance of bringing that
> back as a option?  Also, is there a way to turn off the password
> requests for scgi_ctrl stop/restart?  I''m not in a shared hosting
> environment so I don''t see that it brings me any extra security.
> 
Yep, plans are in the works for bringing that all back.  I removed it
because I had some instability problems with it.  Basically, there''s
not much guarantee that Ruby''s fork and subsequent socket use is a
solid pattern.  It *mostly* worked, but not as well as I thought
originally.

As for DRb, the actual SCGI protocol implementation doesn''t use any
DRb.  That''s in the SCGI::Controller.  If you don''t want to
use DRb, you
can use the -D option for the scgi_ctrl config command and it will
disable DRb.  Then you just need to use the signals that are available.
Everything that DRb does you can do with signals, so you could easily
just use signals.

I''m looking at the other options you want for the next release.  As
soon as I can confirm that it''s stable.

If I can''t get the original simple clustering to work, then
I''m looking
at adding a Rails generator for Apache and Lighttpd configuration that
will work with your scgi_cluster setup.  That would hopefully give you
the same simplicity.

Zed A. Shaw
http://www.zedshaw.com/