Re: [etch-users] Push Configuration

[Phillip S. <fu...@gm...>]

On 27 March 2012 12:54, Jason Heiss <jh...@ap...> wrote:

Thanks for your thoughtful reply; nice to get a good response from a dev
instead of a black-and-white "no" :)


> The problem with the first approach is that you're going to beat up your
> etch servers with the heavy polling, most of which is useless (since you
> will be pushing out of cycle updates very infrequently relative to the
> polling frequency).  If your environment is relatively small this may be
> acceptable though.  I can imagine ways to use the existing "tag"
> functionality to make this work.  For example, you could have in cron:
>

Agreed... While this is a (very) small site, I still hate
"hammer-to-crack-nut" solutions ;)


>
> * * * * *   etch --generate-all --tag urgent
> 0 * * * *  etch --generate-all
>
> /etc/etchserver/urgent could normally be an empty directory, but if you
> had something urgent to push you could populate that directory with an
> updated config repository.  Once all the clients had picked up the change
> and the change had propagated into your normal tags then you could clean
> the urgent directory out again.  You could get fancier with adding a
> timestamp to the tag (i.e. urgent-`date +%Y%m%d%H%M`) and then you wouldn't
> have to bother with cleaning out the directory.
>

I will have to read up more on tags to fully understand this suggestion,
but it still has load implications for the server, and
"hammer-to-crack-nut" feel to it.



> I've thought about building a special daemon that just listens on a port
> and if it gets a connection it runs etch.  That would probably be faster
> than using ssh, but in the end I've always decided it's not worth the
> effort.  It would be pretty easy to do though if you wanted that approach.
>

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.