On Fri, 20 Jun 2014 05:03:24 -0400 shawn wilson <ag4ve...@gmail.com> wrote:
> What I'd like to do is have thin appliances that are managed with chef > or puppet (leaning to puppet). So what I'm thinking is to have one vm > client install with everything the automation system needs to run > (except creds) and network/hostname stuff - have another fs for that. > And a third fs for the actual installed package. > > However, I an issue - I don't know how to make rules for which fs gets > updated. I'm thinking everything needs to overlay at the same point, > so directory writes might go to one fs or another - I think the base > should generally be ro, but the automation config and the 'thin' image > will both update /etc and I need some way of saying "this file gets > updated on fs, this file gets updated on another, and this file goes > to both". And then as I 'strace -e trace=stat64' or whatever and see > what the process touches, I'm going to want to copy it from one fs to > the other (kinda the same issue). > > Is there some mechanism to do this? > If you want "per-directory" control - * create multiple (rw) overlay directory(ies) * create that part of the over-all directory tree in the overlay it should be stored in **before** creating the aufs stack. I.E: one overlay with /etc already existing, one with /home existing, - whatever layer - directory relationship you need * then use those "pre-configured" directory(ies) in the aufs stack. For instance, you might want a per-overlay layout of: /everything else \<<-- leave this rw blank, aufs will fill-in structure /home/.ssh \<<-- this rw layer will capture the credentials /home \<<-- this rw will capture all other /home/* austack aufs_mnt_point Even the standard build of aufs will handle more layers than the human mind is likely to be able to keep track of. ;) Note: The above filter usage should also work at the file level - but I never tested that use. I wrote up using an aufs stack as a "filter" several years ago - - Have since lost the link to my own work, but I never took it down. Mike > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk > Solutions Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems
