Re: [etch-users] using etch + svn externals

[Jason H. <jh...@ap...>]

I'd rate it somewhere between clever and kinda bad, just because svn externals seem to end up sucking every time I use them.

The alternative would be to use a script (i.e. <script> instead of <plain>) to generate the file, and have the script read or generate the config file in such a way that you don't have to store a duplicate copy of the data.  That would be somewhat more in the "traditional" etch way of doing things.

Jason

On Jun 22, 2011, at 9:33 AM, Pat O'Brien wrote:

> Just wanted to run this by the etch-users list to see if this was either a) a bad idea or b) an exceptionally bad idea.
> 
> We have some processes (that some of you will be familiar with) which automatically updates a bind9 zone's serial and generates PTR zones after parsing through the forward zones. This is done in an svn repo outside of etch since we'd rather have the updates go out immediately rather than in 1-4 hours. It also generates two separate files - include_ptr.conf.master and include_ptr.conf.slave. The master's get this file just fine since when updates are pushed it just simply does an svn up, but most of the slaves configs are in etch so the current way of doing this was to just manually copy over the file whenever we'd need to add a new subnet to DNS. We've recently added some more subnets (we already have about 200 for a single datacenter, so why not add some more?) at which point I forgot to update the file in etch. Oops.
> 
> I gave it a few minutes thought and figured I would try out adding this file as an svn external to etch:
> 
> wordup:var pobrien$ tree
> .
> ├── named
> │   └── chroot
> │       └── etc
> │           ├── include_ptr.conf
> │           │   ├── README
> │           │   ├── config.xml
> │           │   └── svn_external
> │           │       └── include_ptr.conf
> │           │           └── include_ptr.conf
> 
> config.xml:
> <config>
>   <depend>/var/named/chroot/etc/named.conf</depend>
>   <file>
>   <comment_line>// </comment_line>
>     <source>
>       <plain operatingsystem="/RedHat|CentOS/" group="dns-resolver">svn_external/include_ptr.conf/include_ptr.conf</plain>
>     </source>
>   </file>
> </config>
> 
> wordup:var pobrien$ svn status
> X       named/chroot/etc/include_ptr.conf/svn_external/include_ptr.conf
> 
> 
> svn:props are set to pull the latest version of the file, it's fairly clearly marked that the file is being provided by an svn external, and our automation can continue on without me forgetting to update this file.
> 
> So, back to the original question - is this a bad idea or an exceptionally bad idea? I didn't see anything about this documented anywhere on the etch wiki. Is there a better way of doing this?
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev_______________________________________________
> etch-users mailing list
> etc...@li...
> https://lists.sourceforge.net/lists/listinfo/etch-users