Puppet

I found another issue, may be the same thing if Puppet is generally stripping out control characters from variables before using them… I have an ugly definition which does search/replace stuff:

define search_replace($search, $line) {
    Exec {
        path => "/bin:/sbin:/usr/bin:/usr/sbin",
    }

    # this is a slightly nasty hack to backup the file before the edit
    exec { search-replace-backup:
        command => "filebucket --remote backup '${name}'",
        unless => "egrep '^${line}$' '${name}'",
        path => "/bin:/sbin:/usr/bin:/usr/sbin",
        logoutput => true,
        notify => Exec["replace"],
    }
    
    exec { replace:
        command => "sed -r -i -e 's/${search}/${line}/' ${name}",
        unless => "egrep '^${line}$' '${name}'",
        path => "/bin:/sbin:/usr/bin:/usr/sbin",
        refreshonly => true,
    }
}

In a manifest I have the following:

        # fix default umask settings
        search_replace { "/etc/bashrc":
            search => "^.*umask 022$",
            line => "   umask 0072";
        }

Note that in the above case I have defined “line” to be “\tumask 0072” – it has a leading tab.

I find that the search/replace is continually running the first exec because it can’t find the line. I see that in the seemingly correctly-edited file the tab has been replaced with 8 spaces. So somewhere in the search/replace the tab is being interpreted as spaces rather than left as a control character.

I can’t reproduce the reported problems in 0.24.5.

With the following manifest:

file { "/tmp/x^M":
  ensure => "/usr/bin/perl";
}

(Where @^M@ is produced with ^V^M in vi)

I get a file in /tmp named “x^M" (or "x?” depending on whether you’re viewing it with tab completion or @ls@) that points to /usr/bin/perl. I’ve also tested “self-referential” links, like so:

file { "/tmp/x^M":
  ensure => "/tmp/x";
}

And I still don’t get any problems.

For the tab problem, I tried this:

file { "/tmp/x":
  content => "     xyzzy";
}

(Where the whitespace in the quotes is a tab, not spaces) I get a file that is 6 bytes in size, containing a tab and five alpha characters.

Given mpalmer’s test cases were run through puppet rather than puppetd my theory is currently that the stripping out of control characters must occur in the puppetmaster or at some point in tranmission to the client, perhaps in the encoding stage into or out of XML.

ohookins wrote:

Given mpalmer’s test cases were run through puppet rather than puppetd my theory is currently that the stripping out of control characters must occur in the puppetmaster or at some point in tranmission to the client, perhaps in the encoding stage into or out of XML.

That should be easy to test, right?

OK here we go:

/tmp/puppet/test.pp:

file { "/tmp/puppet/link^M":
        ensure => "/tmp/puppet/test.pp";
}

Run through “puppet -d -v test.pp” results in:

root@captain:/tmp/puppet# ls -la
total 4
drwxr-xr-x  2 root root  80 2008-10-31 12:00 .
drwxrwxrwt 17 root root 420 2008-10-31 12:00 ..
lrwxrwxrwx  1 root root  19 2008-10-31 12:00 link? -> /tmp/puppet/test.pp
-rw-r--r--  1 root root  64 2008-10-31 12:00 test.pp

All looks good here. I then inserted the exact same file resource into the node config on my staging server, and ran “puppetd —onetime —no-daemonize —ignorecache -d -v” on the node:

debug: //Node[captain]/File[/tmp/puppet/link]: File does not exist
debug: //Node[captain]/File[/tmp/puppet/link]: Changing ensure
debug: //Node[captain]/File[/tmp/puppet/link]: 1 change(s)
debug: //Node[captain]/File[/tmp/puppet/link]/mode: Not managing symlink mode
notice: //Node[captain]/File[/tmp/puppet/link]/ensure: created

The filesystem shows:

root@captain:/tmp/puppet# ls -la
total 4
drwxr-xr-x  2 root root  80 2008-10-31 12:08 .
drwxrwxrwt 17 root root 440 2008-10-31 12:08 ..
lrwxrwxrwx  1 root root  19 2008-10-31 12:08 link -> /tmp/puppet/test.pp
-rw-r--r--  1 root root  64 2008-10-31 12:00 test.pp

No ^M !

In the XMLRPC conversation the ^M seems to be encoded in %2Ftmp%2Fpuppet%2Flink%0D (there’s a %0A after that, as usual for the endline). So, the puppetmasterd appears to be transmitting the carriage return (%0D) properly to the client. Beyond that I cannot hypothesize, as I’m not familiar with puppet internals enough yet.

Yeah, I get this behaviour, too, even in the newest master code.