Re: [etch-users] Push Configuration

[Pat O'B. <obr...@gm...>]

This conversation got me fairly interested in remotely triggering etch, so
I wrote an etch daemon that replaces the functionality that the current
"etch_wrapper" script which we run out of cron, and also adds the ability
to remotely trigger etch, using sinatra+webrick.

https://github.com/poblahblahblah/etchd

I'll add a gemspec file sooner or later and probably break out some things
into a config file (/etc/etch/etchd.conf) or some such. I was thinking
about an "etchctl" script which you could user to trigger etch runs across
multiple machines simultaneously.

This could use better exit and status handling, but to trigger on the
command line you can do something like this:

curl -k -d "my_pass=super_secret_password"
https://client.colo.domain.com/run_etch/trunk

this would run etch against the "trunk" tag, if you want to run it against
a specific tag, you would do this:

curl -k -d "my_pass=super_secret_password"
https://client.colo.domain.com/run_etch/tag-2011032601

You will have to generate a password hash and paste it in the etchd.rb,
here is how you would do that using BCrypt in ruby:


-----snip-----
require 'rubygems'
require 'bcrypt'

puts BCrypt::Engine.hash_secret("super_secret_password",
BCrypt::Engine.generate_salt)
-----snip-----

You'll also want to generate a self signed key and cert and put them as
/etc/etch/etchd.crt and /etc/etch/etchd.key - these should probably be
broken out into a config file as well.

Anyway, it's pretty rough, but it seems to work well in the testing I've
done with it, so if there is any interest beyond our own needs I'll develop
it further and eventually push it over to the sourceforge repo.

-pat


On Tue, Mar 27, 2012 at 6:27 AM, Jason Heiss <jh...@ap...> wrote:

>
> On Mar 26, 2012, at 10:08 PM, Phillip Smith wrote:
>
> > That would be perfect IMHO... If I had any skills in Ruby I would have a
> crack at doing this myself. Technically it's not pushing, just provoking
> the client to initiate a pull on demand, but it achieves the same result;
> changes are propagated promptly.
> >
> > I imagine it would introduce a small security implication since the
> daemon would have to be run as root to be able to spawn etch as root, but
> legitimate connections would come from a known source so could be
> firewalled easily.
>
> The daemon would need to run as root (or have NOPASSWD sudo to run etch),
> but if that's all it could do, didn't accept any specific commands or
> options from the network, etc. then the only security implications would be
> denial of service if someone pinged it continuously.  At worst you'd just
> have the resource consumption of etch running continuously on your systems
> if someone triggered it constantly.
>
> But using some sort of shared secret like Pat suggested probably is a good
> idea to reduce the chance of that.
>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> etch-users mailing list
> etc...@li...
> https://lists.sourceforge.net/lists/listinfo/etch-users
>
>