On Jun 7, 2013 2:51 AM, "John Johansen" <<a href="mailto:john.johansen@canonical.com">john.johansen@canonical.com</a>> wrote: > > On 06/06/2013 01:58 PM, Kshitij Gupta wrote: > > Hello, > > > > @John as suggested I used the configparser module and as it turns out we do have a problem with using it. Actually in the config files at present the default section is represented by an empty string (for e.g. in /etc/apparmor/easyprof.conf ), but configparser needs a none empty section header and hence raises an Error for the same. > > > > I think we should change the format and hence default section headers should be something like [DEFAULT] instead of an empty string. > > > Hrmm, no. easyprof.conf has already shipped, as such unless we have a really good reason to break backwards compatibility we don't. > > Also easyprof.conf is not the config file you should be looking at, or at least not initially > > genprof/logprof have used > > logprof.conf and repository.cong > Yes I did try the tools on logprof.conf for which both worked perfectly. However, I expected the tool to breakdown on the default section case which it did. There's no reason to have different parsers for different config files. Maybe you could work the issue out in AppArmor3. :-) > > Also, the order in which the config parser writes to output file is random (expected of a dictionary) and not sorted. > > > > > Does this matter? Generally our configs and policy have been declarative where order is irrelevant. However if config parser is not the right tool for the job don't use it. I have never actually used it, I just know it exists and uses a format that is close if not the same as what we where using so it is worth looking at. If after looking at it you decide it isn't the right tool, then just tell us so and don't use it. > No, I too suppose the order does not matter. I was merely stating it. In my understanding I should work with the previous version, instead of the one using configparser and will use that, unless somebody gave a solution for the problem. Regards, Kshitij Gupta