On Tue, Oct 20, 2009 at 11:02:19AM -0400, Anurag S. Maskey wrote: > > Michael Hunter wrote: >> Please look at /net/coupe.eng/builds/mph/nwam1_work/webrev for: >> [...] > net-loc:599-603 Hate to add another complexity to the User location, but > "ipfilter-config-file" is hacked to achieve two different things. Its > commented in net-nwam:267-270. If firewall_config_default/policy > property of ipfilter is set to "none", "allow", or "deny", > ipfilter-config-file saves this value as /none, /allow, or /deny > respectively (The / is necessary because the property expects an > absolute path). If the policy property is "custom", then > ipfilter-config-file has the path to file (just like the other > *-config-file) properties. There is no need to append to the > copy_user_files script if /none, /allow or /deny exist.
Hmm. This is a problem for the User location. If we claim that it will activate your environment as it existed prior to upgrade, AND it's a first-class Location, you need to be able to apply it at any time. That means the profile needs to contain the value of the policy property, and the Location script needs to be able to apply that property value when activating the location. We *could* hack around not having an explicit policy property in the User loc by simply saving things as they are in the Legacy loc, and then when activating a location, checking for those special values and setting the ipfilter service's policy property accordingly (instead of always setting it to custom and copying over a file, which I believe is what we do now). I think that's the least invasive approcah. Actually adding an ipfilter-policy property to the location is appealing, and less hacky; but I think would require us to provide more complete support for the ipfilter firewall config than we do right now, and is too much to take on prior to integration. Thoughts? -renee
