[Backgroundrb-devel] Question about acls

[Stephen Weiss]

Hi,

I'm not much of a developer but I've been using backgroundrb for a  
while now and with the release of 0.2.1 it looks like I can finally  
upgrade from the old version (0.2.0 had some weird issues when jobs  
just wouldn't run, seems to have cleared up now - Thanks!).

Anyhow, while I'm doing this, I would like to tackle this problem.   
Most tasks I run in the background involve image processing so  
they're rather processor-intensive, and it's not very good to have  
them running on the same machine that's running rails - it slows  
things down a lot.  I would like to keep running rails on my main  
server (server1) but move backgroundrb to a secondary server (server2).

I looked through the source trying to figure out how to do this and I  
pieced together this configuration file:

--
:port: 22222
:timer_sleep: 60
:pool_size: 15
:load_rails: true
:rails_env: development
:environment: development
:host: localhost
:uri: druby://localhost:22222/
:database_yml: config/database.yml
:protocol: druby
:acl:
   :deny: all
   :allow: localhost 127.0.0.1 server1
   :order: deny,allow
autostart:
   1:
     job_key: chat_notifier
     class: chat_notification_worker

Which runs on server2.  (I know, some of the options probably don't  
belong there but when it's set up on a standalone server it works,  
so...)

I'm using the druby protocol, which I'm pretty sure works over TCP  
instead of UDP, which seems to be what I want.

This all runs fine, except that it seems like my acl is completely  
ignored or maybe it's just not written properly.  If I try to connect  
just using telnet to test whether or not the port is open, I can  
connect to the IPv6 localhost (::1) port 22222 from server2 just  
fine.  However, I can't connect to IPv4 localhost (127.0.0.1) port  
22222 from server2, and I definitely can't connect to server2 port  
22222 from server1.

I can run `script/backgroundrb console` OK from server2 as long  
as :uri is set to "druby://localhost:22222/" and :host is set to  
"localhost".  If I set :host to "server2" then backgroundrb runs, but  
the console fails with:

/usr/local/lib/ruby/1.8/drb/drb.rb:736:in `open': druby://localhost: 
22222 - #<Errno::ECONNREFUSED: Connection refused - connect(2)>  
(DRb::DRbConnError)
         from /usr/local/lib/ruby/1.8/drb/drb.rb:729:in `each'
         from /usr/local/lib/ruby/1.8/drb/drb.rb:729:in `open'
         from /usr/local/lib/ruby/1.8/drb/drb.rb:1189:in `initialize'
         from /usr/local/lib/ruby/1.8/drb/drb.rb:1169:in `new'
         from /usr/local/lib/ruby/1.8/drb/drb.rb:1169:in `open'
         from /usr/local/lib/ruby/1.8/drb/drb.rb:1085:in  
`method_missing'
         from /usr/local/lib/ruby/1.8/drb/drb.rb:1103:in `with_friend'
         from /usr/local/lib/ruby/1.8/drb/drb.rb:1084:in  
`method_missing'
          ... 8 levels...
         from /web/trunk/vendor/plugins/backgroundrb/server/lib/ 
backgroundrb/console.rb:9:in `backgroundrb_console_start'
         from /web/trunk/vendor/plugins/backgroundrb/server/lib/ 
backgroundrb/console.rb:39:in `init'
         from /web/trunk/vendor/plugins/backgroundrb/server/lib/ 
backgroundrb_server.rb:296:in `run'
         from script/backgroundrb:29

I thought maybe since it was pointing to localhost, and Mac OS X  
(this is running on OS X Server 10.4, both machines) has ::1 set up  
as the first resolved address for localhost, maybe backgroundrb was  
being confused into going only over IPv6, but using the IPv4 address  
completely doesn't work?  I've tried various combinations of  
localhost, server2, and server2's ip address in both the :host  
and :uri options with no success, unless both point to localhost, and  
no matter what I do, I can only connect via IPv6 localhost, despite  
the fact that my ACL allows connections from 127.0.0.1 and from  
server1 as well.  Setting the acl to :allow => "all" did not change a  
thing.

I know next to nothing about drb so if I'm missing something  
blatantly obvious I apologize.  Would really like to get this set up  
soon, even a cheap hack that'll work for the next week or so would be  
a godsend.  TIA for any help!

--
Steve