Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am using the IniFile module with augeas to create a Splunk management lens. This works well for all files containing section headers like a normal INI file but there are a couple files that don't follow this scheme, just using the name=value pairs.

Is there a ready way to map these entries without a section defined to something generic, like main? I'd rather not have to learn another module for this second file type of there is a ready way to avoid it for the moment.

module Splunk =
  autoload xfm

  let comment  = IniFile.comment IniFile.comment_re IniFile.comment_default
  let sep      = IniFile.sep IniFile.sep_re IniFile.sep_default

  let setting   = IniFile.record_re
  let title     = IniFile.title ( IniFile.record_re  )
  let entry     = IniFile.entry steting sep comment
  let record    = IniFile.record title entry
  let lns       = IniFile.lns record comment

  let filter    = incl "/etc/splunk/*.conf"
  let xfm       = transform lns filter

  test lns get "[section]\ntest-value=yes\n" = ?
  test lns get "test=yes\n" = ?
share|improve this question

1 Answer 1

up vote 4 down vote accepted

The PHP lens provides similar functionality, supporting settings in an INI file before the defined sections. I've adapted this into your lens and fixed the "setting" lens which should have used IniFile.entry_re to avoid ambiguities.

module Splunk =
  autoload xfm

  let comment  = IniFile.comment IniFile.comment_re IniFile.comment_default
  let sep      = IniFile.sep IniFile.sep_re IniFile.sep_default
  let empty    = IniFile.empty

  let setting   = IniFile.entry_re
  let title     = IniFile.title ( IniFile.record_re - ".anon" )
  let entry     = IniFile.entry setting sep comment
  let record    = IniFile.record title entry
  let record_anon = [ label ".anon" . ( entry | empty )+ ]

  let lns       = record_anon | record*

  let filter    = incl "/etc/splunk/*.conf"
  let xfm       = transform lns filter

  test lns get "[section]\ntest-value=yes\n" = ?
  test lns get "test=yes\n" = ?

The tree that will be generated looks like this, with all settings outside the section sitting under the ".anon" node:

Test result: splunk.aug:20.2-.31:
  { ".anon"
    { "test" = "yes" }
  }

This node is necessary to avoid ambiguities in the put direction. Taking an example, if you were tasked with writing this tree back into a file:

{ "foo" }

It could be written as either just [foo] (a section name) or foo= (a setting outside a section). The ".anon" subtree ensures this transformation back is free of ambiguity. To remove it and have a flat structure, you would need to create a second module/lens for each type of file, which I think would be a more natural solution. The ".anon" node makes more sense in the PHP case where there's a mix in the same file.

Please do submit your lens(es) to the Augeas project when you're done and have added tests, we'd be keen to include it. Submit either via trac or send to the list.

share|improve this answer
    
Will do, thanks. I thought about writing two different sets of files but it is potentially possible to get both sets existing in the same file and run into the same problem. –  Tim Brigham Jun 19 '12 at 13:15
    
Ok, sounds best to take the PHP lens approach then. –  m0dlx Jun 19 '12 at 21:10

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.