0

I have an entry that may or may not appear in /etc/rsyslog.conf:

# Added for Kiwi
*.err;*.emerg;*.alert;*.warning;*.debug;*.notice;*.crit;*.info          @10.19.24.50

Since some of these servers would have had this manually keyed in, I can't assume the whitespace is uniform (and it does vary on at least two servers I've found). I'm trying to write a puppet module for removing these lines.

Relevant segment of that module:

  file_line {'remove_kiwi_comment':

    ensure => absent,
    path   => $confFile,
    match  => "^#.*Kiwi$",
    line   => "# Added for Kiwi",
    match_for_absence => true,

  }

  file_line {'remove_kiwi_forward2':

    ensure => absent,
    match_for_absence => true,
    path   => $confFile,
    match  => '^.*50$',
    line   => '*.err;*.emerg;*.alert;*.warning;*.debug;*.notice;*.crit;*.info @10.19.24.50',
    notify => Service[$serviceName],

  }

The above succeeds in removing the comment from one of the DEV servers but the actual redirect doesn't appear to be removed. I've played around with the regexp in match=> to no avail and I'm not sure what else I can try to get it to delete the line. If I add enough spaces, it will remove it, but I don't want my module to assume any amount of whitespace, just that there is some amount of whitespace present in order to get rsyslog to load.

Stdlib module version is 4.11, master is 3.3, client node for this server is 3.6

  • Just remove the line => directive in each. That should work. – Otheus Apr 19 '16 at 12:06
  • That parameter is required and removing it results in the catalog no longer compiling. – Bratchley Apr 19 '16 at 12:20
  • Then give it the empty string. – Otheus Apr 20 '16 at 8:42
  • line=> has to match the regexp in match=> otherwise it fails then as well. I think I found my solution, though. There's a syslog module out there (by herculesteam) that works for me and is built ontop of Augeas. I think I'll write up a solution for this one problem using Augeas directly and make mention of the module. – Bratchley Apr 20 '16 at 11:57
  • 1
    Whatever you're comfortable with. :) However, I had to laugh hard at "the puppet language ... reads .. like English ... with no technical understanding". – Otheus Apr 20 '16 at 16:42
0

The file_line type has an after option which should work for you. The only problem will be you need to make sure the rule is removed before the comment.

file_line {'remove_kiwi_comment':
    ensure => absent,
    path   => $confFile,
    match  => '^#.*Kiwi$',
    line   => '# Added for Kiwi',
    match_for_absence => true,
}

file_line {'remove_kiwi_forward2':
    ensure => absent,
    path   => $confFile,
    line   => '# Added for Kiwi',
    after  => '^#.*Kiwi$',
    before => File_line['remove_kiwi_comment'],
    notify => Service[$serviceName],
}

If you can't trust that the comment will be in the file, the simplest solution I can think of is to use exec with sed.

exec { 'remove-kiwi-rsyslog-line-with-sed':
    command => "sed -i '/@10\.19\.24\.50$/d' $confFile",
    path    => '/usr/bin:/bin',
    onlyif  => "grep -q '@10.19.24.50$' $confFile",
}

This will only run the exec if the ip address 10.19.24.50 is in the file.

  • I don't think that's going to work for me because your version of file_line['remove_kiwi_forward2'] matches for the text found on the comment line. That part is getting deleted by File_line['remove_kiwi_comment'], it's the part with the actual forward that doesn't seem to be getting deleted even if I make match=> super vague. – Bratchley Apr 18 '16 at 17:52
  • That is what I was saying about the after option in file_line. The remove_kiwi_forward2 will look for the comment and then delete the line after the match (whatever it is). Notice I make sure forward2 runs before remove_kiwi_comment. You'd have to be sure your comment is directly before the rule but if that is the case it should work for you. I tested on a file with 4 lines foo bar baz blah and I was able to delete baz by matching after => '^bar$' without any issues. – Rothgar Apr 18 '16 at 20:10
  • This question could probably be closed as a duplicate of this one with a relevant answer to use augeas instead here – Rothgar Apr 18 '16 at 20:20
  • I don't want to key off removal of a comment that I can't be sure will be there either. The only thing that's certain is that it will be pointed at a particular IP address. You also can't mark as duplicate if the answer is on another SE website or if there's no accepted answer, both of which are true of what you linked. Not to mention using Augeas is just mentioned in passing. It doesn't provide any examples of how to do it. – Bratchley Apr 18 '16 at 20:28
  • I've looked into Augeas and would like to get it to work but I haven't been able to get any help from anyone on that one either. – Bratchley Apr 18 '16 at 20:29
0

For deleting redirection line try to use this one,

file_line {'remove_kiwi_forward2':

    ensure => absent,
    match_for_absence => true,
    path   => $confFile,
    match  => '^.*50$',
    line   => '\*.err;\*.emerg;\*.alert;\*.warning;\*.debug;\*.notice;\*.crit;\*.info.*@10.19.24.50',
    notify => Service[$serviceName],
}
0

After researching it a bit more I found out that file_line is more or less a best-effort attempt at non-invasive configuration file management. There were many other people making complaints similar to mine. The general consensus seems to be to use file_line when you want easy to read puppet modules but bail on that at the first sign of trouble and start using Augeas for all else

The final version of my temporary puppet module:

class kiwiprep {

  if ($::syslogng == "ABSENT"){

    case $::operatingsystemmajrelease {

      /^5/: {

        $serviceName="syslog"
        $confFile="/etc/syslog.conf"

      }

      /^(6|7)/: {

        $serviceName="rsyslog"
        $confFile="/etc/rsyslog.conf"

      }

      default:{
        fail("Platform Not Supported")
      }

    }

    service {$serviceName:
      ensure => running,
      enable => true,
    }

    file_line {'remove_kiwi_comment':

      ensure => absent,
      path   => $confFile,
      match  => "^#.*Kiwi$",
      line   => "# Added for Kiwi",
      match_for_absence => true,

    }

    augeas {"kiwi forwarder 1":
      context => "/files$confFile",
      changes => ["rm *[descendant::hostname = '10.19.24.50']"],
    }

    augeas {"kiwi forwarder 2":
      context => "/files$confFile",
      changes => ["rm *[descendant::hostname = '10.18.104.50']"],
    }


  }

}

(you'll note that this is RHEL-specific, alternations would need to be made for SUSE or Debian)

As you can see my final module kept the file_line for the comment, which works fine for me. Then I reverted to augeas for removing any top level object who had a descendant named hostname whose value was the same as one of my forwarders. This module has worked flawlessly for me when it comes to cleaning up the environment. I will then go back to using file_line to add the new forwarders into place now that I've cleaned up the old one.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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