We are using rcs to manage a few files here and there, when a full vcs is overkill. It is good for managing individual files. Someone once created a script called rcsedit [http://doug.warner.fm/d/content/rcsedit]. One problem it has is that if you rcsedit a file with root, but the file has permissions other than 444 and root:root, it loses them all. I created an update that saves the old perms, selinux context, and acls, if present.
ACLs are saved and restored with getfacl/setfacl. Permissions and selinux context are managed using puppet if it is available, otherwise they are read with stat(1) and written using chown, chmod, and chcon.
A trick was determining whether acls are enabled on the filesystem.
Code is at https://bitbucket.org/riffraff169/rcsedit
I seem to have found an selinux policy for corosync that works:
policy_module(corosync, 1.0)
require {
type corosync_t;
type var_run_t;
type selinux_config_t;
class dir {create setattr read };
class capability { chown };
')
allow corosync_t self:capability chown;
allow corosync_t selinux_config_t: dir read;
allow corosync_t var_run_t:dir { create setattr };
Also you need to add:
setsebool allow_ypbind 1
I had a need to manage local selinux file contexts with puppet, so I came up with the following little puppet recipe:
class selinux::fcontext ( $context = "", $pathname = "", $policy = "targeted" ) {
if ( $context == "" ) or ( $pathname == "" ) {
fail("context and pathname must not be empty")
}
exec { "add_${context}_${pathname}":
command => "semanage fcontext -a -t ${context} \"${pathname}\"",
unless => "semanage fcontext -l|grep \"^${pathname}.*:${context}:\"",
}
}
It is used like this:
class { "selinux::fcontext":
context => "mysqld_log_t",
pathname => "/var/log/mysql(/.*)?",
}
This will add the file context to the local selinux policy if it doesn’t already exist. I may rewrite it for more options later, but I’ve tested it and it works so far. I may write a full module (I’ve got more selinux stuff in this selinux module) and upload to forge.puppetlabs.com.
This should be saved as fcontext.pp in modules/selinux/manifests.
Update: Changed unless condition because it didn’t work right. Now it only runs the command if it isn’t found in the context already.
The Calendar class in Pike (http://pike.roxen.com) is really powerful, but very complex. I needed to parse a time and find out the number of days since 1 Jan 1970. This is what I came up with:
> object b=Calendar.dwim_day(“1 jan 1970″);
Result: Day(Thu 1 Jan 1970)
> b+15313;
Result: Day(Mon 5 Dec 2011)
I need to find the way to create the 2 dates and get the number of days between them.
Some of my puppet nodes took 20 seconds for the augeas portion to complete. I sped it up by only loading the lenses and files the augeas recipe needed to complete:
augeas { “nozeroconf”:
incl => “/etc/sysconfig/network”,
lens => “Shellvars.lns”,
context => “/files/etc/sysconfig/network”,
changes => “set NOZEROCONF yes”,
onlyif => “get NOZEROCONF != yes”,
}
The incl parameter tells it to only load the file specified, rather than every file from every lens, and the lens tells it to only load that specific lens. The lens is given by the module name in the file, for example /usr/share/augeas/lenses/dist/shellvars.aug says module Shellvars, so it is Shellvars.lns.
Adding incl and lens to my augeas types reduced the augeas portion from around 20 seconds to ~5 secs, and in one case less than 1.
A good article about dumb security ideas:
http://www.ranum.com/security/computer_security/editorials/dumb/
Hiera is used for dynamic lookup of variables in a hierarchical manner. It is also used to separate data from the recipes. Here are several links to articles and stuff about hiera:
https://github.com/puppetlabs/hiera
http://www.craigdunn.org/2011/10/puppet-configuration-variables-and-hiera/
